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.
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?
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 :-) ...
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
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.
now enabled by default. While this will hopefully improve thesecurity of most installations, it is technically a backwards
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 349 |
Nodes: | 16 (3 / 13) |
Uptime: | 138:17:33 |
Calls: | 7,613 |
Calls today: | 1 |
Files: | 12,789 |
Messages: | 5,685,991 |