* Tomas Pospisek <t...@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
