Re: directory sticky bit strangeness following libc6 update

On Fri, Apr 17, 2020 at 02:17:46PM -0500, Bob Tracy wrote:
> All,
> 
> This likely isn't unique to Debian, much less the alpha platform, but
> I first encountered this strangeness on my alpha running Debian unstable.
> 
> Best way to explain what I'm seeing is by example.  A fairly common
> thing to do is create temporary or download directories with octal mode
> 1777 that are accessible by everyone.  The directory can be read/written
> by everyone, but users (with the exception of "root") cannot delete files
> in the directory that they do not own.  Otherwise, normal file
> permissions are applied as far as operations that can be performed on a
> particular file, and the expected (pre-libc6 update) behavior is that
> "root" can do anything with a particular file in the absence of extended
> ACL or selinux interference.  "/var/tmp" is one such directory, and a
> thing I like to do is maintain a list of currently-installed packages by
> running "dpkg -l > packages" in that directory as a normal user.

it seems the difference lies in handling of O_CREAT.

    # ls -ldn /var/tmp /var/tmp/hello
    drwxrwxrwt 4    0    0 183 Apr 18 10:37 /var/tmp
    -rw-rw-r-- 1 1002 1002  14 Apr 18 10:37 /var/tmp/hello

    # echo 'howdy' >>/var/tmp/hello
    bash: /var/tmp/hello: Permission denied

    # cat /var/tmp/hello
    hello, world!

    # strace -f sh -c "echo 'howdy' >>/var/tmp/hello" 2>&1 | grep /var/tmp/hello | grep openat
    openat(AT_FDCWD, "/var/tmp/hello", O_WRONLY|O_CREAT|O_APPEND, 0666) = -1 EACCES (Permission denied)


same permission problem with perl sysopen:

    # strace -f -e trace=file 2>&1 perl -e 'use Fcntl; sysopen(my $fh, "/var/tmp/hello", O_WRONLY|O_CREAT|O_APPEND); print $fh "howdy\n"; close $fh;' | grep /var/tmp/hello
    openat(AT_FDCWD, "/var/tmp/hello", O_WRONLY|O_CREAT|O_APPEND|O_CLOEXEC, 0666) = -1 EACCES (Permission denied)


but success when leaving out O_CREAT (also removes the creation umask argument in openat call):

    # strace -f -e trace=file 2>&1 perl -e 'use Fcntl; sysopen(my $fh, "/var/tmp/hello", O_WRONLY|O_APPEND); print $fh "howdy\n"; close $fh;' | grep /var/tmp/hello
    openat(AT_FDCWD, "/var/tmp/hello", O_WRONLY|O_APPEND|O_CLOEXEC) = 3

    # ls -ldn /var/tmp/hello
    -rw-rw-r-- 1 1002 1002 20 Apr 18 11:51 /var/tmp/hello

    # cat /var/tmp/hello
    hello, world!
    howdy



not Alpha specific; this was done on x86_64 Ubuntu 20.04 beta:

    # uname -a; dpkg -l 'libc6' | grep ^.i
    Linux xyz 5.4.0-24-generic #28-Ubuntu SMP Thu Apr 9 22:16:42 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
    ii  libc6:amd64    2.31-0ubuntu7 amd64        GNU C Library: Shared libraries


same kernel installed on an x86_64 Ubuntu 18.04, I get no "Permission denied":

    # uname -a; dpkg -l 'libc6' | grep ^.i
    Linux xyz18 5.4.0-24-generic #28-Ubuntu SMP Thu Apr 9 22:16:42 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
    ii  libc6:amd64    2.27-3ubuntu1 amd64        GNU C Library: Shared libraries


So it seems not to be caused by the kernel version; strange how the same
syscalls give different results depending on libc version.

If the rules had changed, it should not succeed even without
O_CREAT. A bug?


Regards
Matthias Ferdinand