1. Forum
  2. Usenet
  3. LINUX.DEBIAN.DEVEL.TESTIN

  • No permissions to write to other users 777 file in sticky bit dir, even

    From MichaIng@21:1/5 to All on Tue Dec 8 18:00:01 2020
    Hey guys,

    since the (Bullseye) testing list seems to fit better, let me summarize
    the issue that I reported to user list initially: https://lists.debian.org/debian-user/2020/12/msg00122.html

    - Inside a directory with sticky bit set, even the root user is not able/permitted to write to files that are not owned by him, regardless
    of file and directory modes (aside of the directories sticky bit).

    - root can remove the file (which is what the sticky bit should prevent
    for non-root users) and can create own files of course, it can even
    change owner/modes of the file, but it cannot write to it.

    - It doesn't matter how the file write is done, i.e. regardless of shell
    or invoking program (like a Python or PHP script), it fails all with permissions denied.

    - The issue happens on all systems with current Debian Bullseye userland installed, regardless of kernel or hardware, tested with arm64 kernel
    from Buster and Buster backports on x86_64 VM and notebook and current
    stable Linux 5.4 kernel from Raspberry Pi Foundation on a Raspberry Pi 2
    that is using the official Debian repository for everything no kernel/bootloader/firmware related.

    - The issue happens on tmpfs and ext4 file systems, so assumed to happen
    on all file system types that support UNIX permission modes.

    - It was tested to move from systemd to SysV to be able to remove
    libapparmor1, even purging udev, but the issue persists. The systems
    were otherwise very minimal, comparable to fresh mini.iso install
    without additional software selected.

    Steps to reproduce:
    1. Boot into a Debian Bullseye root user shell.
    2. mkdir -m 1777 testdir
    3. > testdir/testfile
    4. chown nobody testdir/testfile
    5. >> testdir/testfile

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From MichaIng@21:1/5 to All on Tue Dec 8 22:40:01 2020
    Okay, the reason has been found:

    - https://lists.debian.org/debian-user/2020/12/msg00305.html

    - https://patchwork.kernel.org/project/kernel-hardening/patch/20180416175918.GA13494@beast/

    Since Debian Bullseye sysctl fs.protected_regular defaults to "2", which
    denies every attempt of a O_CREAT write to a file, that is not owned by oneself, inside a world-writeable sticky bit directory.

    The problem I have with this:

    - It practically breaks writeable sharing files through /tmp between
    multiple users/processes, since O_CREAT is involved in many regular file
    write methods, like shell redirects, but this is expected for the
    security purpose.

    - It is not documented anywhere related to /tmp or the sticky bit, so at
    least on my end it was totally unexpected, especially when something
    does not work anymore that one was used to until Debian Buster.

    - root user is currently included, while it is permitted to remove any
    file in a sticky bit directory, which is the actual documented intention
    of the sticky bit. So IMO root user should be taken out of this
    restrictions. But I'm not sure if this is even possible when this is a kernel-level feature?

    So not sure how to handle best:

    - Add info about those additional restrictions to the chmod man page: https://manpages.debian.org/testing/coreutils/chmod.1.en.html#RESTRICTED_DELETION_FLAG_OR_STICKY_BIT

    - Likely there are many other docs around modes where this info is
    missing. Here I did find it: https://manpages.debian.org/testing/manpages/proc.5.en.html#Files_and_directories

    - Revert fs.protected_regular to default "0" to not break what
    previously worked without a very clear documentation and changelog,
    probably extended error messages about that, if even possible at such a
    level? That is actually what I would vote for since all software I know
    places sensitive files into restricted sub directories of /tmp or /run
    and/or use systemd's PrivateTmp anyway. So if someone really needs to
    have this extra bit of security, it can always be enabled manually, but
    as a default that breaks things in a hard to debug and unexpected way is
    not a good default, IMO.

    Best regards and stay healthy,

    Micha

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