• directory sticky bit strangeness following libc6 update

    From Bob Tracy@21:1/5 to All on Fri Apr 17 21:50:02 2020
    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.

    Prior to the libc6 update, "root" could update that file with an editor
    or by running the same "dpkg -l > packages" command. After the libc6
    update, "root" can't do anything with the file except delete it. The
    file's owner is the only user that can update it, EVEN IF THE FILE
    PERMISSIONS ALLOW WRITING BY EVERYONE. Even more odd: "root" can change
    the permissions on the file to, say, "-rw-rw-rw-", and STILL cannot
    update the file.

    Outside of the directory having the sticky bit set, "root" can still do anything/everything to another user's files as expected.

    I'm currently running an up-to-date "unstable" distro. Kernel version
    is 5.5.0, and libc6 is "libc6.1:alpha 2.30-4".

    Maybe the rules have changed. If so, a pointer to the relevant
    documentation would be appreciated.

    Thanks.
    --Bob

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Matthias Ferdinand@21:1/5 to Bob Tracy on Sat Apr 18 12:40:01 2020
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Bob Tracy@21:1/5 to Matthias Ferdinand on Sat Apr 18 14:50:01 2020
    On Sat, Apr 18, 2020 at 12:25:11PM +0200, Matthias Ferdinand wrote:
    On Fri, Apr 17, 2020 at 02:17:46PM -0500, Bob Tracy wrote:
    (directory sticky bit handling strangeness)

    it seems the difference lies in handling of O_CREAT.

    (...)

    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?

    That's *my* take on the matter. It will be a day or so before I can
    check upstream and see if any bug reports have been opened against
    libc6, but if someone else would care to look in the meantime :-) ...

    --Bob

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Matthias Ferdinand@21:1/5 to Bob Tracy on Sun Apr 19 01:10:01 2020
    On Sat, Apr 18, 2020 at 07:48:27AM -0500, Bob Tracy wrote:
    If the rules had changed, it should not succeed even without
    O_CREAT. A bug?

    That's *my* take on the matter. It will be a day or so before I can
    check upstream and see if any bug reports have been opened against
    libc6, but if someone else would care to look in the meantime :-) ...

    found https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954230, added
    O_CREAT information to it.

    Matthias Ferdinand

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Bob Tracy@21:1/5 to Matthias Ferdinand on Mon Apr 20 02:20:01 2020
    On Sun, Apr 19, 2020 at 01:01:17AM +0200, Matthias Ferdinand wrote:
    On Sat, Apr 18, 2020 at 07:48:27AM -0500, Bob Tracy wrote:
    If the rules had changed, it should not succeed even without
    O_CREAT. A bug?

    That's *my* take on the matter. It will be a day or so before I can
    check upstream and see if any bug reports have been opened against
    libc6, but if someone else would care to look in the meantime :-) ...

    found https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954230, added
    O_CREAT information to it.

    Matthias Ferdinand

    An update to that bug report suggested checking
    /proc/sys/fs/protected_regular, which is now set to 2 by default on my
    alpha. No idea where the new setting is coming from. It's a sysctl
    setting that has evidently been around for a good while. Other systems
    I have access to that are running the same kernel have that value set
    to 0. So I guess the current verdict is, "works as documented". Would
    still like to know what changed, because it's not being touched by the
    kernel build process: else, the other systems running the same kernel
    would be exhibiting the same behavior.

    --Bob

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Matthias Ferdinand@21:1/5 to Bob Tracy on Mon Apr 20 09:10:02 2020
    On Sun, Apr 19, 2020 at 07:11:56PM -0500, Bob Tracy wrote:
    On Sun, Apr 19, 2020 at 01:01:17AM +0200, Matthias Ferdinand wrote:
    On Sat, Apr 18, 2020 at 07:48:27AM -0500, Bob Tracy wrote:
    If the rules had changed, it should not succeed even without
    O_CREAT. A bug?

    That's *my* take on the matter. It will be a day or so before I can check upstream and see if any bug reports have been opened against
    libc6, but if someone else would care to look in the meantime :-) ...

    found https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954230, added O_CREAT information to it.

    Matthias Ferdinand

    An update to that bug report suggested checking /proc/sys/fs/protected_regular, which is now set to 2 by default on my
    alpha. No idea where the new setting is coming from. It's a sysctl
    setting that has evidently been around for a good while. Other systems
    I have access to that are running the same kernel have that value set
    to 0. So I guess the current verdict is, "works as documented". Would
    still like to know what changed, because it's not being touched by the
    kernel build process: else, the other systems running the same kernel
    would be exhibiting the same behavior.

    systemd seems to be setting this. From /usr/share/doc/systemd/NEWS.gz:
    ...
    CHANGES WITH 241:
    ...
    * The fs.protected_regular and fs.protected_fifos sysctls, which were
    added in Linux 4.19 to make some data spoofing attacks harder, are
    now enabled by default. While this will hopefully improve the
    security of most installations, it is technically a backwards
    incompatible change; to disable these sysctls again, place the
    following lines in /etc/sysctl.d/60-protected.conf or a similar file:

    fs.protected_regular = 0
    fs.protected_fifos = 0

    Still not sure why there is different behaviour appending to a file
    depending on using O_CREAT or not.

    Matthias

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)