Re: No permissions to write to other users 777 file in sticky bit dir, even as root
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
Reply to: