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 400 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:amd642.31-0ubuntu7 amd64GNU 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:amd642.27-3ubuntu1 amd64GNU 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
