Previously, in 13.2 and Leap the su command did not need the "-" to get the full --login PATH env variable. I forget when this changed. In Leap-15 it appears to have changed back to the MUCH older way. 13.2: #su # echo $PATH /sbin:/usr/sbin:/usr/local/sbin:/root/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games:/usr/lib/mit/bin:/usr/lib/mit/sbin Leap 42.3: #su # echo $PATH /sbin:/usr/sbin:/usr/local/sbin:/root/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games:/usr/lib/mit/bin:/usr/lib/mit/sbin Leap-15: #su # echo $PATH /sbin:/bin:/usr/sbin:/usr/bin # su - # echo $PATH /sbin:/usr/sbin:/usr/local/sbin:/root/bin:/usr/local/bin:/usr/bin:/bin:/usr/lib/mit/bin:/usr/lib/mit/sbin Just curious if that was intended? Regards Mark -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* Mark Hounschell <markh@compro.net> [04-13-18 14:36]:
Previously, in 13.2 and Leap the su command did not need the "-" to get the full --login PATH env variable. I forget when this changed. In Leap-15 it appears to have changed back to the MUCH older way. 13.2: #su # echo $PATH /sbin:/usr/sbin:/usr/local/sbin:/root/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games:/usr/lib/mit/bin:/usr/lib/mit/sbin
Leap 42.3: #su # echo $PATH /sbin:/usr/sbin:/usr/local/sbin:/root/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games:/usr/lib/mit/bin:/usr/lib/mit/sbin
Leap-15: #su # echo $PATH /sbin:/bin:/usr/sbin:/usr/bin
# su - # echo $PATH /sbin:/usr/sbin:/usr/local/sbin:/root/bin:/usr/local/bin:/usr/bin:/bin:/usr/lib/mit/bin:/usr/lib/mit/sbin
Just curious if that was intended?
probably a local setting as I don't recall "su" ever defaulting to root environment. I always use "su - " sometimes adding <user>. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/13/2018 02:39 PM, Patrick Shanahan wrote:
* Mark Hounschell <markh@compro.net> [04-13-18 14:36]:
Previously, in 13.2 and Leap the su command did not need the "-" to get the full --login PATH env variable. I forget when this changed. In Leap-15 it appears to have changed back to the MUCH older way. 13.2: #su # echo $PATH /sbin:/usr/sbin:/usr/local/sbin:/root/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games:/usr/lib/mit/bin:/usr/lib/mit/sbin
Leap 42.3: #su # echo $PATH /sbin:/usr/sbin:/usr/local/sbin:/root/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games:/usr/lib/mit/bin:/usr/lib/mit/sbin
Leap-15: #su # echo $PATH /sbin:/bin:/usr/sbin:/usr/bin
# su - # echo $PATH /sbin:/usr/sbin:/usr/local/sbin:/root/bin:/usr/local/bin:/usr/bin:/bin:/usr/lib/mit/bin:/usr/lib/mit/sbin
Just curious if that was intended?
probably a local setting as I don't recall "su" ever defaulting to root environment. I always use "su - " sometimes adding <user>.
Well, I haven't made any "local" setting that changed the behavior. That setting appears to be in /etc/default/su. I forget when I noticed the change, but it was quite some time ago. Leap-15 has changed it back. Leap-42.3: # cat /leap/etc/default/su # Per default, only "su -" will set a new PATH. # If this variable is changed to "yes" (default is "no"), # every su call will overwrite the PATH variable. ALWAYS_SET_PATH=no Leap-15: # cat /etc/default/su # Per default, only "su -" will set a new PATH. # If this variable is set to "yes" (default is "no"), # every su call will overwrite the PATH variable. # # The recommended default is "yes". The default "no" behavior could have # a security implication in applications that use commands without path. ALWAYS_SET_PATH=yes So it is clearly a change in behavior but that comment answers my question. It appears to be an intended change. Regards Mark -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 13/04/18 02:39 PM, Patrick Shanahan wrote:
probably a local setting as I don't recall "su" ever defaulting to root
MAN SU(1) says When called without arguments, su defaults to running an interactive shell as root. For backward compatibility, su defaults to not change the current directory and to only set the environment variables HOME and SHELL (plus USER and LOGNAME if the target user is not root). That is certainly how it has behaved for me though 10.x on to my present 42.3. I can see why tumbleweed or 15.x should change that without announcement of same. Check your man pages. AND On 13/04/18 03:09 PM, Mark Hounschell wrote:
Leap-15: # cat /etc/default/su # Per default, only "su -" will set a new PATH. # If this variable is set to "yes" (default is "no"), # every su call will overwrite the PATH variable. # # The recommended default is "yes". The default "no" behavior could have # a security implication in applications that use commands without path. ALWAYS_SET_PATH=yes
So it is clearly a change in behavior but that comment answers my question. It appears to be an intended change.
Ah, very apropos. But ...
Well, I haven't made any "local" setting that changed the behavior.
I had. My su'd path for root: # echo $PATH /sbin:/usr/sbin:/usr/local/sbin:/root/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games Aparently I was a bit paranoid some wya back :-) I'm open to criticism on that. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 14/04/18 08:49 AM, Anton Aylward wrote:
My su'd path for root:
# echo $PATH /sbin:/usr/sbin:/usr/local/sbin:/root/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games
Aparently I was a bit paranoid some wya back :-)
I'm open to criticism on that.
OBtW: Do grep /etc/* for "/usr/local/sbin" first :-) -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Hello, On Sat, 14 Apr 2018, Anton Aylward wrote:
I can see why tumbleweed or 15.x should change that without announcement of same. Check your man pages.
Also, check your /etc/sudoers! Here, PATH is always reset: ==== Defaults targetpw Defaults always_set_home Defaults env_reset Defaults env_keep = "DISPLAY TERM LANG" Defaults env_check = "DISPLAY TERM LANG" Defaults passwd_timeout=1 Defaults timestamp_timeout=0 Defaults insults root ALL=(ALL) ALL dh localhost=(target_user) NOPASSWD:/usr/local/bin/foo "" [and more along that line, where needed, foo is a wrapper, so I have complete control over parameters allowed] ==== And yes, _that_ what a user (or a group) may do, they can do without a password. Anything else requires the target- i.e. usually root-password. The "usual" "sudo anything" only works with entering the root-pw. And while I'm doing that, why not get rid of it in a controlled fashion so that NOPASSWD can be used, eh? BTW: there's _tons_ of stuff out there using 'sudo whatever', when all that's required is using a path, i.e. /sbin/whatever. Latest offender: an article used 'sudo ls /dev/tty*'... Since when is /dev/ without o+rX? Or 'sudo modinfo bla' or 'sudo lsmod'. Could be stuff under /lib/$(uname -r) is not readable, but even on bleeding edge distros it's still: # ls -l /sbin/modinfo /sbin/lsmod /bin/kmod /lib/modules/ -rwxr-xr-x 1 root root 186024 Jan 14 08:07 /bin/kmod* lrwxrwxrwx 1 root root 11 Jan 14 08:07 /sbin/lsmod -> ../bin/kmod* lrwxrwxrwx 1 root root 11 Jan 14 08:07 /sbin/modinfo -> ../bin/kmod* /lib/modules/: total 44 drwxr-xr-x 9 root root 4096 Apr 9 05:11 ./ drwxr-xr-x 16 root root 12288 Apr 14 02:16 ../ drwxr-xr-x 6 root root 4096 Apr 9 05:32 4.16.1-dnh1/ [..] ^^^!!! And on my old install: # ls -l /bin/lsmod /sbin/modinfo -rwxr-xr-x 1 root root 6432 Sep 26 2012 /bin/lsmod -rwxr-xr-x 1 root root 31312 Sep 26 2012 /sbin/modinfo So, /sbin/modinfo, /sbin/lsmod, or just using kmod works just fine. Oh, unless you ran depmod as root with a umask of "xx7" or so, so that user's can't access that file anymore. Anyway: most stuff about sudo "out there" is just plain [elided]... And if I have to fiddle on such a system, first thing is open an xterm and type 'sudo su -'. Bloody [elided]. Was it *buntu or Debian that started this? SuSE had some pretty good sudoers-defaults back when. -dnh -- It's 106 ms latency to Chicago, we've got a fullscale rant about NetSol and half a pack of work annoyances, it's dark, and we're typing with sunglasses.'' -- Hit it.'' -- Anthony de Boer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-04-14 15:48, David Haller wrote:
And yes, _that_ what a user (or a group) may do, they can do without a password. Anything else requires the target- i.e. usually root-password.
The "usual" "sudo anything" only works with entering the root-pw. And while I'm doing that, why not get rid of it in a controlled fashion so that NOPASSWD can be used, eh?
That's an ubuntuization. The normal thing to do was to ask the user password, and limit which users could do what. If I know the root password, I use "su -", become root, and forget that sudo nuisance. Less letters to type. The sudoers file comes not-configured by default on openSUSE, to make the installation easier. Once installed, the file is changed to limit things and people. It says as much in the comments of the file... -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
On 14/04/18 09:48 AM, David Haller wrote:
Hello,
On Sat, 14 Apr 2018, Anton Aylward wrote:
I can see why tumbleweed or 15.x should change that without announcement of same. Check your man pages. Also, check your /etc/sudoers!
Su and sudo are different and distinct commands, configured differently. They can be used to the same end, yes. Given the long terms existence of su, how come we have sudo? I may be a dinosaur in this opinion but I agree with Rob Pike about "Cat -v considered harmful" and the principle therein. Sometimes programmers get too self indulgent. Given that su can do the job, the "policy driven" sudo seems to be programming indulgence at its extreme. Lets not get the two of them confused. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-04-14 22:13, Anton Aylward wrote:
On 14/04/18 09:48 AM, David Haller wrote:
Hello,
On Sat, 14 Apr 2018, Anton Aylward wrote:
I can see why tumbleweed or 15.x should change that without announcement of same. Check your man pages. Also, check your /etc/sudoers!
Su and sudo are different and distinct commands, configured differently. They can be used to the same end, yes. Given the long terms existence of su, how come we have sudo?
Because sudo allows a plain user to call a root only program without knowing the root password. That was its purpose. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
On 14/04/18 11:19 PM, Carlos E. R. wrote:
On 2018-04-14 22:13, Anton Aylward wrote:
On 14/04/18 09:48 AM, David Haller wrote:
Hello,
On Sat, 14 Apr 2018, Anton Aylward wrote:
I can see why tumbleweed or 15.x should change that without announcement of same. Check your man pages. Also, check your /etc/sudoers!
Su and sudo are different and distinct commands, configured differently. They can be used to the same end, yes. Given the long terms existence of su, how come we have sudo?
Because sudo allows a plain user to call a root only program without knowing the root password. That was its purpose.
That I can understand, the needle-sharp delegation of a specific function makes sense; UNIX has often being criticised as root doing every aspect of system administration and no compartmentalization and delegation. having a UUCP administrator, a line printer administrator, an new account administrator ... yes, that's the more 'corporate' approach. Overcoming what is essentially an architectural shortcoming of the simple-but-powerful access control mechanism is one thing. Simply handing out a root shell is quite anther matter. Perhaps a Richie-designed 'sudo' would have made more sense than 'su'? But mu observation of 'sudo' being progrmatically overloaded still holds. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-04-15 13:51, Anton Aylward wrote:
On 14/04/18 11:19 PM, Carlos E. R. wrote:
On 2018-04-14 22:13, Anton Aylward wrote:
On 14/04/18 09:48 AM, David Haller wrote:
Hello,
On Sat, 14 Apr 2018, Anton Aylward wrote:
I can see why tumbleweed or 15.x should change that without announcement of same. Check your man pages. Also, check your /etc/sudoers!
Su and sudo are different and distinct commands, configured differently. They can be used to the same end, yes. Given the long terms existence of su, how come we have sudo?
Because sudo allows a plain user to call a root only program without knowing the root password. That was its purpose.
That I can understand, the needle-sharp delegation of a specific function makes sense; UNIX has often being criticised as root doing every aspect of system administration and no compartmentalization and delegation. having a UUCP administrator, a line printer administrator, an new account administrator ... yes, that's the more 'corporate' approach.
But it is a hell of a job to create a suitable sudoers file for that compartmentalization.
Overcoming what is essentially an architectural shortcoming of the simple-but-powerful access control mechanism is one thing. Simply handing out a root shell is quite anther matter.
Perhaps a Richie-designed 'sudo' would have made more sense than 'su'? But mu observation of 'sudo' being progrmatically overloaded still holds.
-- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
On Sun, 15 Apr 2018 18:01:01 +0200 "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 2018-04-15 13:51, Anton Aylward wrote:
On 14/04/18 11:19 PM, Carlos E. R. wrote:
On 2018-04-14 22:13, Anton Aylward wrote:
Given the long terms existence of su, how come we have sudo?
Because sudo allows a plain user to call a root only program without knowing the root password. That was its purpose.
That I can understand, the needle-sharp delegation of a specific function makes sense; UNIX has often being criticised as root doing every aspect of system administration and no compartmentalization and delegation. having a UUCP administrator, a line printer administrator, an new account administrator ... yes, that's the more 'corporate' approach.
But it is a hell of a job to create a suitable sudoers file for that compartmentalization.
The first time I came across sudo was in a place where it was used explicitly to be able to log exactly who had carried out an admin task (i.e. allocate blame when it went wrong). I understood why they did that, but personally I've found almost no other use for it. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 15/04/18 12:01 PM, Carlos E. R. wrote:
That I can understand, the needle-sharp delegation of a specific function makes sense; UNIX has often being criticised as root doing every aspect of system administration and no compartmentalization and delegation. having a UUCP administrator, a line printer administrator, an new account administrator ... yes, that's the more 'corporate' approach.
But it is a hell of a job to create a suitable sudoers file for that compartmentalization.
Is is any less of a 'hell of a job' to set that up under a IBM MVS system? As far as I can see just add the users to a relevant group and configure SUDO work in terms of that group. Delegate lp, uucp, policy, .... It's all there, just have to run chkstat . More advanced systems use ldap based account management and sudo can make use of that too. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, 2018-04-15 at 16:04 -0400, Anton Aylward wrote:
On 15/04/18 12:01 PM, Carlos E. R. wrote:
That I can understand, the needle-sharp delegation of a specific function makes sense; UNIX has often being criticised as root doing every aspect of system administration and no compartmentalization and delegation. having a UUCP administrator, a line printer administrator, an new account administrator ... yes, that's the more 'corporate' approach.
But it is a hell of a job to create a suitable sudoers file for that compartmentalization.
Is is any less of a 'hell of a job' to set that up under a IBM MVS system?
As far as I can see just add the users to a relevant group and configure SUDO work in terms of that group.
Delegate lp, uucp, policy, .... It's all there, just have to run chkstat .
Well, the "root" admin has to list somewhere who can do that, seeking all the tools a limited admin has to use, and then correct the errors. There are hundreds of tools to consider. And sometimes a root tool should be used only with some of the options, not all of them. Now, if someone contributed those lists ready made, it would be different. I worked with the Lucent 5ESS, a telephone network exchange, which run unix with a frontend. On one site (say about dozen machines) they set up admin roles, going command by command, adding them to groups, then choosing what people could run each command. It took more than a week to prepare (and I don't know how long to read docs), then another to setup, and weeks to debug (problems with people that could not do their job, people that could not login, etc). Interestingly, some people (me) could get to the unix shell and then do anything.
More advanced systems use ldap based account management and sudo can make use of that too.
I guess. Windows does have this area much more advanced (via AD). You can fine tune who does what, and there are already some roles, like one for doing backups. - -- Cheers, Carlos E. R. (from openSUSE 42.3 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlrUnQcACgkQtTMYHG2NR9VMOACgi92MbjKpdey376Boeo3LpSfl KtUAoJlmu0Gtk3Or1nRKcz1t69V4/J6A =2O7q -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Anton Aylward wrote:
Given the long terms existence of su, how come we have sudo?
It's easier and more reliable to use sudo to run commands since sudo can be configured to preserve things 'su' clears (after a rewrite a few years ago). ENV diffs: su: < DISPLAY=:0.0 < REMOTEHOST= < PS4=+ --- sudo:
DISPLAY=athenae:0 REMOTEHOST=athenae PS1=\[$(titlebar)\]${HOSTNAME}:$(spwd "$PWD")>\[\] PS2=> PS4=>${BASH_SOURCE:+${BASH_SOURCE/$HOME/\~}}#${LINENO}${FUNCNAME:+(${FUNCNAME})}>
--- su clears your XDISPLAY (which I thought could be a security risk, but was overruled) and resets your prompts. I filed a bug about the DISPLAY change, but was told suse had redefined the session and passing through the original host and display was no longer supported, so the bug was closed as rejected or will not fix. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (7)
-
Anton Aylward -
Carlos E. R. -
Dave Howorth -
David Haller -
L A Walsh -
Mark Hounschell -
Patrick Shanahan