On some of my alpine boxes setting the umask to 0077 and subsequently running
mkdir creates a directory with permissions 2700.  Has anybody noticed this
strange behavior?  It appears fixed in the repository, but I'd like to
understand the cause of the issue.

In short I see the following output when running this script:

    umask 0077
    mkdir thing
    ls -ld thing

outputs:

    drwx--S---    2 vagrant  vagrant       4096 Sep 26 18:01 thing

All the machines run 3.12.0, though the affected ones were last updated several
months ago.  In case anybody wants to reproduce the issue I found this will do
it.  This example uses a vagrant box from about two months ago:

1. Create a Vagrantfile with the following contents

    Vagrant.configure("2") do |config|
      config.vm.box = "generic/alpine312"
      config.vm.box_version = '3.0.14'
    end

2. run vagrant up && vagrant ssh

3. in the ssh session run the reproducer

    umask 0077
    mkdir thing
    ls -ld thing

Thanks in advance.
Winston Weinert
https://winny.tech/

Hello,

On 2020-09-26 13:44:57 -0500, Winston Weinert wrote:
> On some of my alpine boxes setting the umask to 0077 and subsequently running
> mkdir creates a directory with permissions 2700.  Has anybody noticed this
> strange behavior?

I think this is in general caused by busybox's adduser setting the sticky
bit on the home directory:

    +   $ podman run -it --rm alpine sh -c '
    adduser -D x
    ls -al /home
    su - x -c "mkdir a"
    su - x -c "umask 0077 && mkdir b"
    ls -al /home/x
    '
    total 0
    drwxr-xr-x    1 root     root             2 Sep 29 16:28 .
    drwxr-xr-x    1 root     root           114 Sep 29 16:26 ..
    drwxr-sr-x    1 x        x                0 Sep 29 16:28 x
    total 0
    drwxr-sr-x    1 x        x                4 Sep 29 16:28 .
    drwxr-xr-x    1 root     root             2 Sep 29 16:28 ..
    drwxr-sr-x    1 x        x                0 Sep 29 16:28 a
    drwx--S---    1 x        x                0 Sep 29 16:28 b

Notice that /home/x already has the bit set. As for the why S is there
even if it all should be 0 bits, from info page of ls:

    But ‘ls’ combines multiple bits into the third character of each set of
    permissions as follows:
    
         ‘s’
              If the set-user-ID or set-group-ID bit and the corresponding
              executable bit are both set.
    
         ‘S’
              If the set-user-ID or set-group-ID bit is set but the
              corresponding executable bit is not set.

So resetting the sgid bit on the home directory should get you the
behavior you seem to look for.

W.

-- 
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.