[opensuse] Problem with suid pgms on Leap-15.0
I am upgrading an older SuSE-13.2 box to Leap. I have done a fresh Leap-15.0 install and ported over the source code that we ran on the 13.2 box. I builds fine but I am having an issue. The program is/has to be an suid pgm. It also uses fork/execvpe/wait to execute some external scripts. And that is where my problem lies. The user is a member of several groups but these group memberships seem to disappear when these external scripts are executed. For instance the user is a member of the cdrom group so he can eject and work with a DVD. I have created a simple example script and source for a pgm that execvpe's that script which shows my problem. test.sh script: #!/bin/sh whoami id test.c pgm source: #define _GNU_SOURCE #include <unistd.h> #include <stdio.h> #include <stdlib.h> #include <string.h> int main() { char *path = getenv("PATH"); char pathenv[strlen(path) + sizeof("PATH=")]; sprintf(pathenv, "PATH=%s", path); char *envp[] = {pathenv, NULL}; char *tests[] = {"./test.sh", NULL}; execvpe(tests[0], tests, envp); } #cc test.c #/a.out markh uid=5076(markh) gid=100(users) groups=100(users),19(floppy),200(lcrs),484(tape),485(lp),488(disk),489(dialout),490(cdrom) 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. This all works fine on 13.2 but does not on Leap 15 or Leap 42.3. Is there some security setting somewhere that broke this? Any help from anyone would be appreciated. Regards Mark -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 06/01/2018 10:20 AM, Mark Hounschell wrote:
I am upgrading an older SuSE-13.2 box to Leap. I have done a fresh Leap-15.0 install and ported over .... 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.
This all works fine on 13.2 but does not on Leap 15 or Leap 42.3. Is there some security setting somewhere that broke this? Any help from anyone would be appreciated.
Regards Mark
Is the pgm forced to drop privileges upon becoming owned by root? AFAIK, Opensuse hasn't been a pure permissions based Linux for some several releases. (Permissions and group membership aren't the only controlling factor any more). ACLs are possibly involved: https://doc.opensuse.org/documentation/leap/security/html/book.security/cha.... Udev rules might be involved (especially when a device is referenced) https://doc.opensuse.org/documentation/leap/reference/html/book.opensuse.ref... -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 06/01/2018 04:21 PM, John Andersen wrote:
On 06/01/2018 10:20 AM, Mark Hounschell wrote:
I am upgrading an older SuSE-13.2 box to Leap. I have done a fresh Leap-15.0 install and ported over .... 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.
This all works fine on 13.2 but does not on Leap 15 or Leap 42.3. Is there some security setting somewhere that broke this? Any help from anyone would be appreciated.
Regards Mark
Is the pgm forced to drop privileges upon becoming owned by root?
No, the sample pgm and script I provided show the problem. It's a simple matter of the group memberships of the user being dropped.
AFAIK, Opensuse hasn't been a pure permissions based Linux for some several releases. (Permissions and group membership aren't the only controlling factor any more).
ACLs are possibly involved: https://doc.opensuse.org/documentation/leap/security/html/book.security/cha.... Udev rules might be involved (especially when a device is referenced) https://doc.opensuse.org/documentation/leap/reference/html/book.opensuse.ref...
The sample pgm I provided does nothing ACL or UDEV related. It simply forks and execs a script that shows the groups the user is a member of. Which is users only. Mark -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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". -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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? Mark -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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
On 06/02/2018 07:56 AM, Andrei Borzenkov wrote:
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.
I don't know about Leap prior to 42.3 but from 42.3 to 15.0 I see the problem. 13.2 works. I have found a work around but I went ahead and filed a bug report. The pgm supplied in the original post is just a sample pgm that shows my problem. In real life I'm actually using fork/exec/wait. Regards Mark -- 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
On 2 June 2018 at 13:56, Andrei Borzenkov <arvidjaar@gmail.com> 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? -- 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 <arvidjaar@gmail.com> 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 3 June 2018 at 08:27, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
03.06.2018 09:08, Richard Brown пишет:
On 2 June 2018 at 13:56, Andrei Borzenkov <arvidjaar@gmail.com> 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?
Can you reference the exact lines in the .dif which you believe are causing this issue? Because that file in general has been in the openSUSE bash package since before a time OBS existed and reading the changelog might even go back as far as the first versions of bash in the earliest SUSE linux versions, with patches pulled from upstream and usenet Kinda hard to do such software archaeology in abstract but if you could help point out some exact lines, maybe I can help figure out how they got there -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
03.06.2018 09:34, Richard Brown пишет:
On 3 June 2018 at 08:27, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
03.06.2018 09:08, Richard Brown пишет:
On 2 June 2018 at 13:56, Andrei Borzenkov <arvidjaar@gmail.com> 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?
Can you reference the exact lines in the .dif which you believe are causing this issue?
@@ -1277,6 +1278,7 @@ disable_priv_mode () { int e; + setgroups(0, NULL); if (setuid (current_user.uid) < 0) { e = errno;
Because that file in general has been in the openSUSE bash package since before a time OBS existed and reading the changelog might even go back as far as the first versions of bash in the earliest SUSE linux versions, with patches pulled from upstream and usenet
Kinda hard to do such software archaeology in abstract but if you could help point out some exact lines, maybe I can help figure out how they got there
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Andrei Borzenkov wrote:
@@ -1277,6 +1278,7 @@ disable_priv_mode () { int e;
+ setgroups(0, NULL); if (setuid (current_user.uid) < 0) { e = errno;
This appears to be a setuid call that would only work when transitioning away from root. I may be misunderstanding the problem, but it seems the original poster had a problem when they transitioned *to* root, so the above code doesn't seem to make sense as being the soul source of problems. Is there something that clears the groups upon a transition to root? Would the above code ever be executed? As I understand it, we are talking about a SETUID program. Aren't privilege transitions handled in the kernel? It seems odd to have such code in a user-level program like a shell. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 06/04/2018 09:27 AM, L A Walsh wrote:
Andrei Borzenkov wrote:
@@ -1277,6 +1278,7 @@ disable_priv_mode () { int e;
+ setgroups(0, NULL); if (setuid (current_user.uid) < 0) { e = errno;
This appears to be a setuid call that would only work when transitioning away from root.
I may be misunderstanding the problem, but it seems the original poster had a problem when they transitioned *to* root, so the above code doesn't seem to make sense as being the soul source of problems.
Is there something that clears the groups upon a transition to root?
Would the above code ever be executed? As I understand it, we are talking about a SETUID program. Aren't privilege transitions handled in the kernel? It seems odd to have such code in a user-level program like a shell.
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. 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. Mark Regards Mark -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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? 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? 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 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? 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? I had some other Q's, but had a phone call come in that caused a stack overflow in my brain....oh well. -- 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
On 06/04/2018 03:11 PM, Mark Hounschell wrote:
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.
BTW, I did find a work around before I got a response from the BUG. child_pid = fork(); if (child_pid == 0) { // child process. // Work around for bug 1095670 getresuid(&cruid, &ceuid, &csuid); // Get real, effective, and saved uids getresgid(&crgid, &cegid, &csgid); // Get real, effective, and saved gids setresuid(cruid, cruid, cruid); // set all uids to real uids setresgid(crgid, crgid, crgid); // set all gids to real gids execvpe(argv[0], argv, envp); // If execvpe returns, it must have failed. perror("lcrs_system(): execvpe failed : "); return -1; } else { // // This is run by the parent. // Wait for the child to exit. // do { tpid = wait(&child_status); if (tpid != child_pid) { printf("Problem with wait\n"); } } while(tpid != child_pid); return child_status; } 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
participants (6)
-
Andrei Borzenkov -
John Andersen -
L A Walsh -
Mark Hounschell -
Mark Hounschell -
Richard Brown