02.06.2018 12:52, Mark Hounschell пишет:

On 06/02/2018 01:07 AM, Andrei Borzenkov wrote:

...

01.06.2018 20:20, Mark Hounschell пишет: ...

...

Then as root: #chown root ./a.out #chgrp root ./a.out #chmod +s ./a.out

Then as user #./a.out

markh

uid=5076(markh) gid=100(users) groups=100(users)

Once the pgm is owned by root and suid, I lose all my group memberships for some unknown reason. It is not proper to me.

man bash

If the shell is started with the effective user (group) id not equal to the real user (group) id ... effective user id is set to the real user id.

It should actually read "effective user (group) id is set to real user (group) id".

OK, so what? The "real" group id is users(100). That's what happens. What does that have to do with group membership of the user being lost?

This appears to be local SUSE patch which additionally resets supplementary groups. There is not much info in changelog and OBS is not entirely helpful in browsing historical versions either, but for all I can tell patch is quite old. Behavior is present in Leap 42.3 already. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Andrei Borzenkov wrote;

This appears to be local SUSE patch which additionally resets supplementary groups. There is not much info in changelog and OBS is not entirely helpful in browsing historical versions either, but for all I can tell patch is quite old. Behavior is present in Leap 42.3 already.

Why does opensuse allow this nonsense? Someone up and applies a patch without it being documented very well and don't even bother to update the associated manpages. Then people wonder why things break randomly. I've heard from people outside of suse, years ago, that open suse's releases were known to have little documented and little known patches that caused O.S. built binaries to not behave as the same programs on other OS's. To the point that opensuse had a reputation for having flakey behaviors in their programs. I didn't know what to say when I heard this, AFAIKnew it was FUD, but I've seen more than one patch like this -- with little justification or documentation. The problem is, that some of them, like this one, affect security. This makes me more than a little less trusting of open-suse patched binaries when it comes to compatibility and documented security behaviors. I ran into a similar attitude that repurposed a pam file for setting the environment once/login session to once per suse-session initialization. Problem was, they aren't the same -- critical security information like how the original logged-in user logged into the system was thrown away (with a side effect of killing a remote display due to the remote host no longer being known). I was told suse was repurposing this for their own session usage and my original usage as documented in the module notes, was no longer important/relevant or whatever. I could enumerate more issues that fit the same pattern, but it seems like someone "in charge" of a program can make changes pretty much however they see fit. Many times over past versions many of these changes cause innumerable problems that are very hard to track down, because no one expects changes of this type -- making such changes lightly would be too likely to cause incompatiblities with other people's usage. On the pam issue I asked why they couldn't fork the module under a new name for suse's session definition use. Nah, not worth it was basically the message I got. Many of those issues I did file bugs on only to have the bug rejected. What's amusing is that on visible things, I'll be told suse stays well behind the curve so as to not cause incompatibilities -- meaning it's only little changes that are not that visible that get changed leaving someone to wonder what happened, and if it will be fixed before some 2-3 year time period is passed and the version they filed it against is no longer supported. I don't know the fix, but it seems like a problem not likely to engender trust and confidence when encountering problems -- especially in things that "used to work". I doubt things can change, it seems to easy to add changes like this, under-the-radar -- which again, seems to be pointing to a huge potential for security issues either accidently or otherwise. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

03.06.2018 09:08, Richard Brown пишет:

On 2 June 2018 at 13:56, Andrei Borzenkov wrote:

...

...

OK, so what? The "real" group id is users(100). That's what happens. What does that have to do with group membership of the user being lost?

This appears to be local SUSE patch which additionally resets supplementary groups. There is not much info in changelog and OBS is not entirely helpful in browsing historical versions either, but for all I can tell patch is quite old. Behavior is present in Leap 42.3 already.

Link to the patch please?

https://bugzilla.opensuse.org/show_bug.cgi?id=1095670 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 06/04/2018 02:29 PM, L A Walsh wrote:

Mark Hounschell wrote:

...

On 06/04/2018 09:27 AM, L A Walsh wrote:

To be clear, and I have tested this, I am not loosing my group memberships when I start the suid pgm or during its execution. They are simply not being passed to an exec'd external entity.

---

    That's not exactly clear to me.

    FWIW, I get annoyed at programs that mess with GID-based access.  Groups are perfect for giving access to multiple accounts owned by the same person, among other things...

1)    Let me repeat that back -- a program running as root (the suid pgm), execs another program and the groups disappear?     OR) do you mean only execution of bash scripts?

Yes, the groups associated with the RUID go away. Both scripts and executables.

2) You say you used to do the exact same thing under 13.2? Using   bash-4.2 and it worked?, but now under Leap-15 and bash-4.???   it doesn't work?

Correct.

3) at what point in executing 'pgm+<whatever>', does the 'job' stop   being 'root' -- or is it your belief that it stays root throughout   execution until pgm terminates?

In the main (suid) pgm, the RUID and RGID remain the user UID and GID. The EUID, EGID, SUID, and SGID remain as root(0). When I execvpe something it executes as RUID and GUID. AND the EUID, GUID, SUID, and SGID are the real USERs (NOT 0) unless it is also an suid executable. And I do have one or 2 of those suid executables. I don't have SUID scripts. Not even sure that actually works. My main program continues execution as I specified the main pgm does above with no change. The child I execvpe, exits when complete, I assume, with the ID's as when it started. But I don't care what happens to it when it exits other than providing me with exit status. I believe the main suid pgm stays that way unless I un SUID it within the code which I do not do.

...

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.

---

    What is 'pgm'?  Is it a binary or some sort of script?     How is the main-process run?  Is it setuid, or do you use a program like 'sudo', 'su', or 'runas' or ???

    How about the main process?  What type of program is it?

The main pgm is an SUID executable. No script. No su, sudo, or runas. Started via command line like any normal pgm.

    In the code I quoted, it looked like it was when resetting groups before it dropped root -- that's why I'm asking if it keeps root while executing everything, or if it drops it at some point, or what, since it sounded like you were saying the groups were dropped when you became root -- but with *this* note, it sounds like that's not the case either, but more in line with a fork or exec?

No, go back and read the OP. I only said that the groups associated with the RUID of the main pgm are gone in the execvpe's task/script. It is not the fork but the execvpe that causes the groups associated with the RUID of the main task to get dropped in the new task/script. Groups are not dropped from the RUID in the main pgm at all. It is only what I execvpe that does not get the group assocations that the RUID should have.

    I had some other Q's, but had a phone call come in that caused a stack overflow in my brain....oh well.

The rpm provided by Dr. Werner Fink seems to have fixed it up. There is a new response to your Bugzilla comment BTW. (In reply to L. A. Walsh from comment #11)

[...] The problem was the loss of supplementary group ID's upon becoming root [...]

Actually, his problem was the loss of supplementary group IDs when transitioning away from root. And that makes sense to me. When I execvpe something, I am transitioning away from root. Mark -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

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