Mark Hounschell wrote:
In the main program, not the example I provided, I fork/exec/wait. The main process still has my group memberships after that. They just don't make it into the exec'd pgm/script.
It seems there is an important difference here. It appears the patch to make this work is in _bash_ -- is that your understanding as well? If that's the case, are you sure the groups also get dropped when exec'ing a non-script program? I can't see how a patch in bash would fix anything other than a bash script. Second question -- do you want the scripts to be executed as 'root' or as the RUID/RGID? It seems you are execing the program (binary or script, not sure yet), as root, and whatever you are executing is dropping the root privs. That would explain the code snippet and patch that affects the groups on transitioning away from root. Observation -- your workaround forces the sub processes to run as root -- and certainly that would get around the problem. Do you want them to run as root? If so, fine. If not, you might switch back to the RUID before you spawn of whatever program(s) you are running. That way, theoretically, you would be in control of the ROOT->RUID transition and avoid any possibility of groups changing due to that being handled in some external program (like bash). Of note -- regarding the fix using "initgroups(3)". If a user has acquired any groups in their session after login, it sounds like they will still lose some groups. The only reliable way I see to avoid the problem is to have the top-level program that is running as EUID root, to transition to whatever UID & groups are needed for proper execution of the children or scripts AFTER the fork and before the exec. The whole idea of randomly resetting groups to some arbitrary user default default makes me queezy. It seems that even though 'bash' appears to think that it should set groups consistent with a particular UID, it doesn't know where those groups came from or where the UID came from. If the program started as user 'joe' who is a member of 'engineers', but not a member of 'finance', it seems that switching the UID to to someone in finance, like 'bob' and executing bash, would give instant access to the 'finance' group that doesn't appear to be audited. Then the script runs another suid prog and resets the UID/RUID to 'joe' (not using bash), then joe gets access to 'finance' w/o, for example, having a usbkey that most in 'finance' need to enter the group (i.e. newgrp calls pam-mod that reads usbkey). So re-initializing the group to the user's default could drop groups acquired, as well as temporarily add groups to a user process. Did I mention that the idea of user-level programs assigning groups made me queezy? Ick.
The rpm provided by Dr. Werner Fink seems to have fixed it up.
For you, but it still introduces new security behaviors that I'm not entirely comfortable with. There may be no problem and I tend to be more paranoid than many, but hey, I compile my own bash, so what do I care, right? ;-) [ :-( waaaah].
And that makes sense to me. When I execvpe something, I am transitioning away from root.
Nope...exec call is in kernel -- they are changing code in bash. It's bash that was patched to drop your groups as per some POSixish recommendation. Now, that's not being done either -- instead the user's original groups are being restore -- which may be fine in your use case, but not sure about the effects in the edges & margins. This is sorta what I meant by how sources can get modified away from what other distros use or vanilla bash, and there's little documentation about how or why it happens -- then in fixing that little patch's side effects, something else might be introduced entirely different from what POSix 'recommended'. I know some of the people making these changes are *WAY* smart, but that doesn't mean breakages can't occur which can be worse when no one even knows the code was modified in some unique opensuse way. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org