* Tomas Pospisek <
tpo@sourcepole.ch> [210903 08:27]:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=993488#16 contains a "wontfix + close" but no rationale. Which leaves the original reporter with
a large "?" I guess.
I am guessing that the reason for the "wontfix" is "that's just how Unix works unfortunately" aka "that's a Unix design bug"? Is my guess correct?
One other question - any idea on a way forward here? I would guess that behaviour (changing group membership won't change group membership of
running processes) is rooted somewhere quite low in the stack, maybe in the kernel itself (or in posix :-#)? So if the original reporter would want to
go ahead and look to that problem beeing fixed would he need to go talk to the kernel mailing list or do you have idea where he could go to?
*t
Attempting to "fix" this can never fully work. One of the fundamental
designs of *nix permissions is that a process can open handles with
current permissions, than drop privileges below what would be necessary
to open those handles, but continue to use those handles.
So, even if the Linux kernel watched for group membership changes, it
could only affect attempts to open new handles, not existing open
handles (otherwise, much existing code intended to increase security
would cease to function without any obvious way to fix it).
I don't think this was a design bug, but rather a conscious design
choice. Just like a process can drop permissions, the process gets is
initial set of permissions from the state of the user db _at process
start_, not dynamically each time a permission-checking system call is
made.
Suppose a root process calls setgroups to add specific supplementary
groups, then sets the uid. One of the groups the process intentionally
set is coincidentally one of the user's additional groups. Now the user
(in the user db) is dropped from that group, but the program was written intentionally to grant that group regardless of the user's group
membership.
In other words, the kernel has no way of knowing whether a process was
granted group access because the user was a member of that group or
because the program running in that process explicitly added that group.
The OP's issue is really only an issue for shells, where one might
expect that a new "command" uses the current user db rather than
inheriting from the shell, which got its permissions from the initial,
rather than current, state of the user db.
Changing the shell behavior to track the user db is fraught with
security issues. Adding new groups would require the shell to maintain CAP_SETGID permissions, and properly retain or drop those permissions
for each created process. This would require the shell to be setuid
root to be able to work correctly in all situations. This is just not
going to happen. It doesn't make much sense to me for the shell to drop removed groups but not add new groups when the user db changes.
So, I think your real answer is "that's just how Unix works
(fortunately)". I really think this should be tagged not-a-bug. :-)
...Marvin
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)