[opensuse-factory] 'su' seems to ignore "-p" (preserve environment)... in factory...
Plays havoc with my remoteX stuff... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, Mar 21, 2013 at 1:49 AM, Linda Walsh <suse@tlinx.org> wrote:
Plays havoc with my remoteX stuff...
It works fine for me. Can you be more specific? I remember some versions (I'm checking 12.2 and doesn't seem to be the case here) that blacklisted DISPLAY and XAUTHORITY, you had to edit your sudoers (talking sudo not su here) to be able to preserve those. In 12.2, XAUTHORITY seems to be automatically created too, although it seems to work fine (I can launch X stuff as sudo just fine, but this is local, might not work remotely) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Claudio Freire wrote:
On Thu, Mar 21, 2013 at 1:49 AM, Linda Walsh <suse@tlinx.org> wrote:
Plays havoc with my remoteX stuff...
It works fine for me.
Can you be more specific?
I remember some versions (I'm checking 12.2 and doesn't seem to be the case here) that blacklisted DISPLAY and XAUTHORITY, you had to edit your sudoers (talking sudo not su here) to be able to preserve those.
Right -- if I sudo bash -i , I don't have the problem -- everything is preserved. But either sudo su -p OR su -p Both reset parts (if not all of) my 'env' -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 03/21/2013 06:29 PM, Linda Walsh pecked at the keyboard and wrote:
Claudio Freire wrote:
On Thu, Mar 21, 2013 at 1:49 AM, Linda Walsh <suse@tlinx.org> wrote:
Plays havoc with my remoteX stuff...
It works fine for me.
Can you be more specific?
I remember some versions (I'm checking 12.2 and doesn't seem to be the case here) that blacklisted DISPLAY and XAUTHORITY, you had to edit your sudoers (talking sudo not su here) to be able to preserve those.
Right -- if I sudo bash -i , I don't have the problem -- everything is preserved.
But either sudo su -p OR su -p Both reset parts (if not all of) my 'env'
If you want to maintain your login env just plain su will do that. I vert highly recommend you DON'T. You will mess up your login. -- Ken Schneider SuSe since Version 5.2, June 1998 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Ken Schneider - openSUSE wrote:
Right -- if I sudo bash -i , I don't have the problem -- everything is preserved.
But either sudo su -p OR su -p Both reset parts (if not all of) my 'env'
If you want to maintain your login env just plain su will do that. I vert highly recommend you DON'T. You will mess up your login.
How does it mess up your login? I don't like using su (also, my 'su' is aliased to 'su -p') by itself -- as I have to type in the password. Thus, I usually use sudo, which used to require a command, so sudo su, was the shortest way to a root prompt while maintaining my environment. Now, sudo has an option that can shortcut that, but old habits have me typing in sudo su about 70% of the time, But that's resetting key variables (majority are NOT changed)... LS_OPTIONS & PATH PS1 REMOTEHOST DISPLAY The ones that cause things to break: PS1, REMOTEHOST, DISPLAY LS_OPTIONS and PATH changes don't seem to be a problem but clearing REMOTEHOST and changing DISPLAY are bad. The change to PS1 chases the window title to no longer be updated with the host and path. ---- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Friday 2013-03-22 18:06, Linda Walsh wrote:
Ken Schneider - openSUSE wrote:
Right -- if I sudo bash -i , I don't have the problem -- everything is preserved.
But either sudo su -p OR su -p Both reset parts (if not all of) my 'env'
If you want to maintain your login env just plain su will do that. I vert highly recommend you DON'T. You will mess up your login.
How does it mess up your login? I don't like using su (also, my 'su' is aliased to 'su -p') by itself -- as I have to type in the password. Thus, I usually use sudo, which used to require a command, so sudo su, was the shortest way to a root prompt while maintaining my environment.
Now, sudo has an option that can shortcut that, but old habits have me typing in sudo su about 70% of the time
And it's kind of dumb. sudo already gives you the root surroundings, so sudo bash would be sufficient. But note that sudo resets the environment by default, which is why 11:48 nakamura:~ > sudo xterm Warning: This program is an suid-root program or is being run by the root user. The full text of the error or warning message cannot be safely formatted in this environment. You may get a more descriptive message by running the program as a non-root user or by removing the suid bit on the executable. xterm: Xt error: Can't open display: %s xterm: DISPLAY is not set 11:48 nakamura:~ > su - -c xterm Passord: <xterm pops up> There is sudo -E, but that still screws around: 11:51 nakamura:~ > sudo -E xterm Warning: Tried to connect to session manager, Authentication Rejected, reason : None of the authentication protocols specified are supported and host-based authentication failed <xterm pops up>
, But that's resetting key variables (majority are NOT changed)...
LS_OPTIONS & PATH
PS1 REMOTEHOST DISPLAY
The ones that cause things to break: PS1, REMOTEHOST, DISPLAY
LS_OPTIONS and PATH changes don't seem to be a problem
LS_OPTIONS, PATH and PS1 are set from /etc/bashrc* and/or /etc/profile*, so that is not directly a su/sudo problem - depending on su options, it either starts a shell, or a login shell, and the login shell definitely reexecutes the profile things. SYNOPSIS su [OPTION]... [-] [USER [ARG]...] DESCRIPTION Change the effective user id and group id to that of USER. -, -l, --login make the shell a login shell -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 03/23/2013 06:55 AM, Jan Engelhardt pecked at the keyboard and wrote:
On Friday 2013-03-22 18:06, Linda Walsh wrote:
Ken Schneider - openSUSE wrote:
Right -- if I sudo bash -i , I don't have the problem -- everything is preserved.
But either sudo su -p OR su -p Both reset parts (if not all of) my 'env'
If you want to maintain your login env just plain su will do that. I very highly recommend you DON'T. You will mess up your login.
How does it mess up your login?
When using su by itself you maintain your personal login env and can change/create files/folders that are owned by root. Then when logging in to your account you can get errors about not having access to those files. Should have said _may_ mess up your login. -- Ken Schneider SuSe since Version 5.2, June 1998 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Ken Schneider - openSUSE wrote:
su -p Both reset parts (if not all of) my 'env'
If you want to maintain your login env just plain su will do that.
Except that it doesn't do that: Ishtar:law> echo $DISPLAY athenae:0 Ishtar:law> 'su' Password: home/law# echo $DISPLAY :0.0 ---- with the "-p" or "-m" it also kept DISPLAY. Now it doesn't. without -p, I get these differences: DISPLAY=athenae:0 | DBUS_SESSION_BUS_ADDRESS=unix:abstrac > DBUS_SESSION_BUS_PID=14207 > DISPLAY=:0.0 HISTFILE=/home/law/.histIshtar_pts/1 | HISTFILE=/root/.histIshtar_pts/1 HOME=/home/law | HOME=/root LS_OPTIONS=-N --color=tty -T 0 | LS_OPTIONS=-A -N --color=tty -T 0 OLDPWD=/etc/rc.d < PATH=.:/sbin:/usr/local/sbin:/home/la | PATH=.:/sbin:/usr/local/sbin:/home/la PATH_HOME=/home/law | PATH_HOME=/root PS1=\[$(titlebar)\]${HOSTNAME}:$(spwd | PS1=\[\]$(spwd "$PWD" )#\[ REMOTEHOST=athenae | REMOTEHOST= SHLVL=1 | SHLVL=2 USER=law | USER=root _bashrc=1 | _bashrc=2 _sh_LOGNAME_=law | _sh_LOGNAME_=root with -p, I get: DISPLAY=athenae:0 | DISPLAY=:0.0 LS_OPTIONS=-N --color=tty -T 0 | LS_OPTIONS=-A -N --color=tty -T 0 OLDPWD=/etc/rc.d < PATH=.:/sbin:/usr/local/sbin:/home/la | PATH=.:/sbin:/usr/local/sbin:/home/la PS1=\[$(titlebar)\]${HOSTNAME}:$(spwd | PS1=\[\]$(spwd "$PWD" )#\[ REMOTEHOST=athenae | REMOTEHOST= SHLVL=1 | SHLVL=2 USER=law | USER=root _bashrc=1 | _bashrc=2 _sh_LOGNAME_=law | _sh_LOGNAME_=root My REMOTEHOST, DISPLAY PS1, and PATH all change. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Jan Engelhardt wrote:
11:48 nakamura:~ > sudo xterm Warning: This program is an suid-root program or is being run by the root user. The full text of the error or warning message cannot be safely formatted in this environment. You may get a more descriptive message by running the program as a non-root user or by removing the suid bit on the executable. xterm: Xt error: Can't open display: %s xterm: DISPLAY is not set
I don't get that: sudo xterm & [1] 6526 Ishtar:law> But when I wanted to su and stay "su'd" for a while: I used sudo su: along with alias su='su -p' DISPLAY and remote host are no longer set in 12.3+ not set.
11:48 nakamura:~ > su - -c xterm Passord: <xterm pops up>
There is sudo -E, but that still screws around:
11:51 nakamura:~ > sudo -E xterm Warning: Tried to connect to session manager, Authentication Rejected, reason : None of the authentication protocols specified are supported and host-based authentication failed
That a reason why I have root and my main login in the same group -- and used group control to manage permissions -- though more programs are breaking that every day as well... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Saturday 2013-03-23 21:33, Linda Walsh wrote:
Jan Engelhardt wrote:
11:48 nakamura:~ > sudo xterm Warning: This program is an suid-root program or is being run by the root user. The full text of the error or warning message cannot be safely formatted in this environment. You may get a more descriptive message by running the program as a non-root user or by removing the suid bit on the executable. xterm: Xt error: Can't open display: %s xterm: DISPLAY is not set
I don't get that:
sudo xterm & [1] 6526 Ishtar:law>
Then you have a nonstandard, nondefault sudo config or something. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Jan Engelhardt wrote:
On Saturday 2013-03-23 21:33, Linda Walsh wrote:
Jan Engelhardt wrote:
11:48 nakamura:~ > sudo xterm Warning: This program is an suid-root program or is being run by the root user. The full text of the error or warning message cannot be safely formatted in this environment. You may get a more descriptive message by running the program as a non-root user or by removing the suid bit on the executable. xterm: Xt error: Can't open display: %s xterm: DISPLAY is not set
I don't get that:
sudo xterm & [1] 6526 Ishtar:law>
Then you have a nonstandard, nondefault sudo config or something.
Um...so? I should be concerned that I have configured my setup to work? Is a working setup a problem? Strike that. Rathole. ---- The issue is with 'su', not sudo: NAME su - run a shell with substitute user and group IDs SYNOPSIS su [OPTION]... [-] [USER [ARG]...] DESCRIPTION Change the effective user id and group id to that of USER. ... -m, --preserve-environment do not reset environment variables -p same as -m --- su -p doesn't work anymore. That's my problem. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sat, 23 Mar 2013 18:26:09 -0700 Linda Walsh <suse@tlinx.org> wrote:
Jan Engelhardt wrote: ...
Then you have a nonstandard, nondefault sudo config or something.
Um...so? I should be concerned that I have configured my setup to work? Is a working setup a problem?
You can have a setup that works, which is for sure not limited to what openSUSE provides. Many other that post on this list have such setups, but then they are on their own, they understand that and don't flood list with requests that boil down to demand that whole distro has to adjust to their ways, as you often do. For instance your 'sudo su' construct is a kludge that works for you. No one have a problem with that, if that makes you happy, but then the only answers that you will receive are those that will state that your way is not openSUSE way, and point that openSUSE way works. A sole purpose of such answers is to point out to readers of our mail list archives that it is not problem with openSUSE setup, but with your customization. What makes your customization not working is another pair of shoes. It can be misunderstood, or obsolete, manual, bug in a software that you use, not implemented functionality, or combination of above. I'm wondering what makes you use non-standard solutions which in a long run deviate more and more from solutions that openSUSE integration and development people choose, abandoning whole a lot of man-hours that they put in integration, forcing you to read the code and fix it with your own unique solutions, or report bugs that affect few people and are not handled promptly, which leads you to more frustration. -- Regards, Rajko. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sun, Mar 24, 2013 at 12:44 PM, Rajko <rmatov101@charter.net> wrote:
I'm wondering what makes you use non-standard solutions which in a long run deviate more and more from solutions that openSUSE integration and development people choose, abandoning whole a lot of man-hours that they put in integration, forcing you to read the code and fix it with your own unique solutions, or report bugs that affect few people and are not handled promptly, which leads you to more frustration.
TBH I've always considered "sudo su" rather common and standard. I have noticed it borks your environment, so where it matters I do use "sudo bash", mostly scripts, but really I wouldn't consider it so far fetched that some people would use "sudo su". -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sun, 24 Mar 2013 16:13:12 -0300 Claudio Freire <klaussfreire@gmail.com> wrote:
TBH I've always considered "sudo su" rather common and standard.
That could be the case in some other distro, but within openSUSE you will find often recommendations to use 'su' and 'su -' and not 'sudo'. Details are buried in the discussions stored in mail list archives, but I would recall if there was any significant chatter about changes regarding this. -- Regards, Rajko. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sun, Mar 24, 2013 at 7:55 PM, Rajko <rmatov101@charter.net> wrote:
TBH I've always considered "sudo su" rather common and standard.
That could be the case in some other distro, but within openSUSE you will find often recommendations to use 'su' and 'su -' and not 'sudo'. Details are buried in the discussions stored in mail list archives, but I would recall if there was any significant chatter about changes regarding this.
Well, I'd consider any recommendation to not use sudo entirely rather ill-suited for most applications where sudo is desired. Ie: when you want to give sudo powers to users without giving them the root password. Which I'd consider an important use case. I thought the recommendation was against the specific "sudo su" idiom. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 25/03/13 00:33, Claudio Freire wrote:
On Sun, Mar 24, 2013 at 7:55 PM, Rajko <rmatov101@charter.net> wrote:
TBH I've always considered "sudo su" rather common and standard.
That could be the case in some other distro, but within openSUSE you will find often recommendations to use 'su' and 'su -' and not 'sudo'. Details are buried in the discussions stored in mail list archives, but I would recall if there was any significant chatter about changes regarding this.
Well, I'd consider any recommendation to not use sudo entirely rather ill-suited for most applications where sudo is desired.
Ie: when you want to give sudo powers to users without giving them the root password. Which I'd consider an important use case.
I thought the recommendation was against the specific "sudo su" idiom.
One of the reasons why sudo is also encouraged is logging. On a shared computer, it is relatively trivial to log every command executed via sudo and then aggregate that information via e.g. logwatch or logcheck or any number of monitoring solutions. For this reason, it might be advisable to actually specifically disallow sudo su, since that circumvents said measures, basically using sudo once to gain a root shell, in which you can go crazy. This is sample output from a Debian 7 box: Mar 25 11:33:24 ares su[8263]: pam_wheel(su:auth): Ignoring access request 'user' for 'root' Mar 25 11:33:29 ares su[8263]: Successful su for root by user Mar 25 11:33:29 ares su[8263]: + /dev/pts/0 user:root Mar 25 11:33:29 ares su[8263]: pam_unix(su:session): session opened for user root by user(uid=1000) Mar 25 11:33:37 ares su[8263]: pam_unix(su:session): session closed for user root Mar 25 11:33:50 ares sudo: user : TTY=pts/0 ; PWD=/home/user ; USER=root ; COMMAND=/usr/bin/less /var/log/auth.log Mar 25 11:33:50 ares sudo: pam_unix(sudo:session): session opened for user root by user(uid=0) The commands executed within the root shell are not logged, however, every single command executed via sudo is. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Mar 25, 2013 at 8:36 AM, Peter Hanisch <veniastra@gmail.com> wrote:
On 25/03/13 00:33, Claudio Freire wrote:
On Sun, Mar 24, 2013 at 7:55 PM, Rajko <rmatov101@charter.net> wrote:
TBH I've always considered "sudo su" rather common and standard.
That could be the case in some other distro, but within openSUSE you will find often recommendations to use 'su' and 'su -' and not 'sudo'. Details are buried in the discussions stored in mail list archives, but I would recall if there was any significant chatter about changes regarding this.
Well, I'd consider any recommendation to not use sudo entirely rather ill-suited for most applications where sudo is desired.
Ie: when you want to give sudo powers to users without giving them the root password. Which I'd consider an important use case.
I thought the recommendation was against the specific "sudo su" idiom.
One of the reasons why sudo is also encouraged is logging. On a shared computer, it is relatively trivial to log every command executed via sudo and then aggregate that information via e.g. logwatch or logcheck or any number of monitoring solutions. For this reason, it might be advisable to actually specifically disallow sudo su, since that circumvents said measures, basically using sudo once to gain a root shell, in which you can go crazy.
Yes, but sometimes it is necessary. For instance, when piping. sudo blabla | grep bleh > /etc/somefile won't work, because the redirect happens in an unprivileged bash. And doing sudo bash -c 'all here' is a mess of string quoting that never comes out right. There's also the "sudo su <user>" which I use a lot sometimes to do "sudo su postgres". So, yes, discourage it must be discouraged, but it sometimes has to be done. I hear sudo bash is preferable in those cases... I tend to agree. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Claudio Freire <klaussfreire@gmail.com> [2013-03-25 16:12]:
On Mon, Mar 25, 2013 at 8:36 AM, Peter Hanisch <veniastra@gmail.com> wrote:
On 25/03/13 00:33, Claudio Freire wrote:
On Sun, Mar 24, 2013 at 7:55 PM, Rajko <rmatov101@charter.net> wrote:
TBH I've always considered "sudo su" rather common and standard.
That could be the case in some other distro, but within openSUSE you will find often recommendations to use 'su' and 'su -' and not 'sudo'. Details are buried in the discussions stored in mail list archives, but I would recall if there was any significant chatter about changes regarding this.
Well, I'd consider any recommendation to not use sudo entirely rather ill-suited for most applications where sudo is desired.
Ie: when you want to give sudo powers to users without giving them the root password. Which I'd consider an important use case.
I thought the recommendation was against the specific "sudo su" idiom.
One of the reasons why sudo is also encouraged is logging. On a shared computer, it is relatively trivial to log every command executed via sudo and then aggregate that information via e.g. logwatch or logcheck or any number of monitoring solutions. For this reason, it might be advisable to actually specifically disallow sudo su, since that circumvents said measures, basically using sudo once to gain a root shell, in which you can go crazy.
Yes, but sometimes it is necessary. For instance, when piping.
sudo blabla | grep bleh > /etc/somefile
won't work, because the redirect happens in an unprivileged bash. And doing sudo bash -c 'all here' is a mess of string quoting that never comes out right.
sudo blabla | grep bleh | sudo tee /etc/somefile >/dev/null is a well-known idiom for addressing this (and other redirections requiring root privileges). -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Mar 25, 2013 at 12:42 PM, Guido Berhoerster <gber@opensuse.org> wrote:
One of the reasons why sudo is also encouraged is logging. On a shared computer, it is relatively trivial to log every command executed via sudo and then aggregate that information via e.g. logwatch or logcheck or any number of monitoring solutions. For this reason, it might be advisable to actually specifically disallow sudo su, since that circumvents said measures, basically using sudo once to gain a root shell, in which you can go crazy.
Yes, but sometimes it is necessary. For instance, when piping.
sudo blabla | grep bleh > /etc/somefile
won't work, because the redirect happens in an unprivileged bash. And doing sudo bash -c 'all here' is a mess of string quoting that never comes out right.
sudo blabla | grep bleh | sudo tee /etc/somefile >/dev/null
is a well-known idiom for addressing this (and other redirections requiring root privileges).
Cool. Always learning. One less reason to use sudo su. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Monday 2013-03-25 12:36, Peter Hanisch wrote:
One of the reasons why sudo is also encouraged is logging.
Mar 25 11:33:50 ares sudo: user : TTY=pts/0 ; PWD=/home/user ; USER=root ; COMMAND=/usr/bin/less /var/log/auth.log
The commands executed within the root shell are not logged, however, every single command executed via sudo is.
Well if people only use 'sudo su' or 'sudo bash', there is not much value in the logs so created. Better use audit or something anyway... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Rajko wrote:
On Sun, 24 Mar 2013 16:13:12 -0300 Claudio Freire <klaussfreire@gmail.com> wrote:
TBH I've always considered "sudo su" rather common and standard.
That could be the case in some other distro, but within openSUSE you will find often recommendations to use 'su' and 'su -' and not 'sudo'.
So you can type su and su- and not have to type a password? How would you configure that? Is password-less usage of 'su' standard with SuSE? I've never heard of it myself. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Friday 2013-03-29 00:51, Linda Walsh wrote:
Rajko wrote:
On Sun, 24 Mar 2013 16:13:12 -0300 Claudio Freire <klaussfreire@gmail.com> wrote:
TBH I've always considered "sudo su" rather common and standard.
That could be the case in some other distro, but within openSUSE you will find often recommendations to use 'su' and 'su -' and not 'sudo'.
So you can type su and su- and not have to type a password?
How would you configure that?
Is password-less usage of 'su' standard with SuSE?
I've never heard of it myself.
Yes, su supports passwordless use, though by default this is only enabled for root for obvious reasons. /etc/pam.d/su:auth sufficient pam_rootok.so You can easily add auth sufficient pam_succeed_if.so quiet use_uid user = jengelh -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Jan Engelhardt wrote:
Is password-less usage of 'su' standard with SuSE? I've never heard of it myself.
Yes, su supports passwordless use, though by default this is only enabled for root for obvious reasons.
/etc/pam.d/su:auth sufficient pam_rootok.so
You can easily add
auth sufficient pam_succeed_if.so quiet use_uid user = jengelh
Interesting... though it's still a problem that su resets HOSTNAME, DISPLAY & PS1, while 'sudo' does not. Also, my most frequent usage is sudo CMD, which 'su' only support indirectly. But adding multiple users or groups to pam configs seems more than a little error prone -- you mess up pam and you can lock everyone out, you mess up sudo, you just have to fix that. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Friday 2013-03-29 01:46, Linda Walsh wrote:
But adding multiple users or groups to pam configs seems more than a little error prone -- you mess up pam and you can lock everyone out, you mess up sudo, you just have to fix that.
If you mess up /etc/pam.d/su, you only mess up su, just like you would only render sudo useless when messing up /etc/sudoers. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday, 2013-03-29 at 02:17 +0100, Jan Engelhardt wrote:
On Friday 2013-03-29 01:46, Linda Walsh wrote:
But adding multiple users or groups to pam configs seems more than a little error prone -- you mess up pam and you can lock everyone out, you mess up sudo, you just have to fix that.
If you mess up /etc/pam.d/su, you only mess up su, just like you would only render sudo useless when messing up /etc/sudoers.
If you use the aproved method of using "visudo", it will do some sanity checks before accepting any edit :-) - -- Cheers, Carlos E. R. (from 12.1 x86_64 "Asparagus" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAlFXeTIACgkQtTMYHG2NR9XlowCfb/tKHDcJMzxikoDMi1TFrKAY +UIAnidMTkehghYJSE2ooxkignyZ+E/w =Hj8w -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, 28 Mar 2013 16:51:52 -0700 Linda Walsh <suse@tlinx.org> wrote:
So you can type su and su- and not have to type a password?
Why would I need 'su' and 'su -' without password? 'sudo' with (default) time limit of 5 min is in my case equal to type root password (default) every time, or in the best case very often, even if I use same command, which is not very often the case. Why would I do that? In openSUSE you have configured administrator's (currently root) terminal and you use that for system administration, no need to configure anything. Almost the same effect you have with 'su -'. The difference it that I know that I have root shell active by background color, which is not the case with 'su -' or 'sudo'. Of course, it is not passwordless. The 'su' command alone will preserve some user environment and taking what is cleared (REMOTEHOST, DISPLAY and few more) it sounds like correction for some security,or privacy, issue(s). I can't help you with that, although I tried to locate at least one CVE. openSUSE Security Team, that can help, seems to be busy doing what they suppose to do, instead of entertaining someone with insatiable appetite for original solutions that often clash with openSUSE defaults. As a side note, you don't have to satisfy spellchecker if you know that compound word is created correctly; in this case paswordless is equally correct as password-less, with only difference that later is not needed hack to satisfy program called spellchecker. You can find both on the web, which tells that you are not alone trying to use "meaning-less" construct with dash for words that are not in a program "data-base", but no human will have trouble to "under-stand" them. -- Regards, Rajko. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Rajko wrote:
On Thu, 28 Mar 2013 16:51:52 -0700 Linda Walsh <suse@tlinx.org> wrote:
So you can type su and su- and not have to type a password?
Why would I need 'su' and 'su -' without password?
'sudo' with (default) time limit of 5 min is in my case equal to type root password (default) every time, or in the best case very often, even if I use same command, which is not very often the case. Why would I do that?
So you can sudo gvim and it will display on your remote terminal? if you sudo bash, does it still tell you you are remotely logged in? Nope. Both of those are common usages. Other things not preserved: proxy settings ls_colors history file HOME exported functions sudo showsize PERL5OPT -- GREP_OPTIONS LS_OPTIONS PS VARIABLES LESSCHARSET
In openSUSE you have configured administrator's (currently root) terminal
---- What administrator's terminal? If I want to perform file-op or service restart and I type make <prod> and you use that for system administration, no need to
configure anything. Almost the same effect you have with 'su -'. The difference it that I know that I have root shell active by background color, which is not the case with 'su -' or 'sudo'. Of course, it is not passwordless.
The 'su' command alone will preserve some user environment and taking what is cleared (REMOTEHOST, DISPLAY and few more) it sounds like correction for some security,or privacy, issue(s). I can't help you with that, although I tried to locate at least one CVE.
openSUSE Security Team, that can help, seems to be busy doing what they suppose to do -- creating custom solutions that break existing standards... and existing security
That doesn't work anymore than clearning them in sudo does. How do I edit a file like /etc/passwd and have it display correctly? if sudo clears display by default, (as does su, now), sudo gvim /etc/passwd ... doesn't show up on my screen. policies. ---- That's exactly the problem. They create custom solutions for custom security configurations which break standard security configs that rely upon standard security configuration.
instead of entertaining someone with insatiable appetite for [the] original [and standard] solutions that often clash with openSUSE defaults.
Yeah... well again... The problem is people write scripts and solutions for the standard behaviors. When the SUSE security team breaks standard behaviors, they break some peoples working security policies and setups. Just like others pointed out 'sudo su' is a standard meme for getting a root shell. Has been for *ages*... it was the original solution -- since sudo didn't offer a shell option until recently (and till doesn't by default). But say you have sudo change your 'home'... now you run vim, -- and does it pick up your .vim files in your home directory or in root's? It used to be that IF you wanted to become ROOT, with ROOT's env, you used "su -", that reinitialized the env to be that of root. That was standard, everyone knew that. su, by itself did minimal reinitialization, and su -p, specifically preserved the environment. Now it is broken.
As a side note, you don't have to satisfy spellchecker if you know
--- So you feel anything goes with english, but with suse, you feel it's only the 'suse' way or you are on your own?.... If you do that, then the words in english get redefined as well and then you have no clear communication as well as random program behavior -- which is documented by unclear language (if it is documented at all)... how useful is that? As for your earlier trash talk: Many other that post on this list have such setups, but then they are on their own, they understand that and don't flood list with requests that boil down to demand that whole distro has to adjust to their ways, as you often do. ---- Oh?... If so many others have non-standard setups maybe suse is no longer meeting the needs of the many. Suse has gone from one of the best all-purpose distro's and is narrowing down to providing "appliances". You put down anyone that asks for support of previous compatibility as them "demanding the whole distro adjust"... how about asking that the whole distro provide for previous compatibility? Compared the largest industry leader... MS, XP went into effect in um... 2001? 2000? XPSP3 is still supported 13 years later? How long does suse support a release? ~ 18 months? If suse supported releases for 5-10 years, then people wouldn't be forced to upgrade every year and there wouldn't be all these issues of constant change killing off compat. I still run winxp scripts on Win7 written 10 years ago. The chances of me doing that with Suse are low without constant maintenance to undo incompatible changes. Sorry, but expecting us to throw away our work every 18 months is unreasonable. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Rajko wrote:
On Sun, 24 Mar 2013 16:13:12 -0300 Claudio Freire <klaussfreire@gmail.com> wrote:
TBH I've always considered "sudo su" rather common and standard.
That could be the case in some other distro, but within openSUSE you will find often recommendations to use 'su' and 'su -' and not 'sudo'.
But sudo doesn't change my environment. su does. That was the point of this discussion. Also sudo -- if you go back to when it first entered suse, DIDN'T reset the environment by default --- it didn't have a BUNCH of options it now has. SuSE took sudo, configured it for their purposes, and left the user with nothing but to go off and use some private copy. Same with perl and vim among others. The problem is that these system utilities are there ***FOR THE USER***, not for the private use of the distro. I use a distro to get precompiled binaries of utils I use, not to have all of my standard utilities taken away and modified to be non-standard and have arbitrary/non-standard functionality. Suse needs to realize -- if the OS NEEDS a non-standard version, it needs to NOT take over the /usr/bin or /bin copies -- but maintain it's own set of "internal-use only"... As it stands, Suse feels free to take over all of /{,usr}/}{s,}bin,lib64}/ and tell users how to use standard programs or not to use them at all. If users want to use those programs, they need to go find a distro that compiles them and load it into /usr/local, in addition to letting suse have all of /usr. That's ridiculous -- that's not serving the users -- that's serving SuSE and telling the users they are on their own if they mess with any of their own system's programs, just like you just did among several others.
A sole purpose of such answers is to point out to readers of our mail list archives that it is not problem with openSUSE setup, but with your customization.
NOT at all -- It's suse that is customizing standard utils not to work in standard ways. My "customizations", as you call them, are to try to get back to standard functionality. So far, the entire venture into systemd and moving all the boot utils to /usr has been pointless and disaster for systems compatibility. No one has come up with any good reason to move all the boot utils to /usr -- No one wants to answer that question. There is no reason why the file systems systemd needs to run can't be mounted by scripts on DISK or initrd, and then started -- or at least no reason that anyone has admitted to -- like "we can't allow user scripts to have control during boot or it will defeat the purpose of secure boot -- which is to kill the personal computer as a general computing device -- which most users do not want! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Friday 2013-03-29 02:04, Linda Walsh wrote:
Rajko wrote:
On Sun, 24 Mar 2013 16:13:12 -0300 Claudio Freire <klaussfreire@gmail.com> wrote:
TBH I've always considered "sudo su" rather common and standard.
That could be the case in some other distro, but within openSUSE you will find often recommendations to use 'su' and 'su -' and not 'sudo'.
But sudo doesn't change my environment. su does.
Well, sucks to be in your environment where everything is upside down all the time.
Also sudo -- if you go back to when it first entered suse, DIDN'T reset the environment by default --- it didn't have a BUNCH of options it now has. SuSE took sudo, configured it for their purposes, and left the user with nothing but to go off and use some private copy. Same with perl and vim among others.
What options? Can you name the patch? The config file lines that cause this? The command line argument? No? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Jan Engelhardt wrote:
What options? Can you name the patch? The config file lines that cause this? The command line argument? No?
--- Yes: It's documented in the sudoers file: ## ## Defaults specification ## ## Prevent environment variables from influencing programs in an ## unexpected or harmful way (CVE-2005-2959, CVE-2005-4158, CVE-2006-0151) Sources for 12.1 show: README.SUSE sudo-grp-include.patch sudo-1.8.2-CVE-2012-0809.patch sudo-sudoers.patch sudo-1.8.2-CVE-2012-2337.patch sudo.pamd sudo-1.8.2-ldap_search_escape.patch sudoers2ldif-env.patch sudo-1.8.2.tar.gz --- In sudo v 1.8.5: you can see all the sudoer changes: -## You may wish to keep some of the following environment variables -## when running commands via sudo. -## -## Locale settings -# Defaults env_keep += "LANG LANGUAGE LINGUAS LC_* _XKB_CHARSET" -## -## Run X applications through sudo; HOME is used to find the -## .Xauthority file. Note that other programs use HOME to find -## configuration files and this may lead to privilege escalation! -# Defaults env_keep += "HOME" -## -## X11 resource path settings -# Defaults env_keep += "XAPPLRESDIR XFILESEARCHPATH XUSERFILESEARCHPATH" -## -## Desktop path settings -# Defaults env_keep += "QTDIR KDEDIR" -## -## Allow sudo-run commands to inherit the callers' ConsoleKit session -# Defaults env_keep += "XDG_SESSION_COOKIE" -## -## Uncomment to enable special input methods. Care should be taken as -## this may allow users to subvert the command being run via sudo. -# Defaults env_keep += "XMODIFIERS GTK_IM_MODULE QT_IM_MODULE QT_IM_SWITCHER" +## Prevent environment variables from influencing programs in an +## unexpected or harmful way (CVE-2005-2959, CVE-2005-4158, CVE-2006-0151) +Defaults always_set_home +Defaults env_reset +## Change env_reset to !env_reset in previous line to keep all environment variables +## Following list will no longer be necessary after this change + +Defaults env_keep = "LANG LC_ADDRESS LC_CTYPE LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE LC_TIME LC_ALL LANGUAGE LINGUAS XDG_SESSION_COOKIE" Defaults were to keep the environment -- suse changes that. Any other questions you need answered that I can pull from the src rpms? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Friday 2013-03-29 03:32, Linda Walsh wrote:
+## Prevent environment variables from influencing programs in an +## unexpected or harmful way (CVE-2005-2959, CVE-2005-4158, CVE-2006-0151) +Defaults always_set_home +Defaults env_reset +## Change env_reset to !env_reset in previous line to keep all environment variables +## Following list will no longer be necessary after this change + +Defaults env_keep = "LANG LC_ADDRESS LC_CTYPE LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE LC_TIME LC_ALL LANGUAGE LINGUAS XDG_SESSION_COOKIE"
Defaults were to keep the environment -- suse changes that.
Well, if you would rather like to have a security issue... see if I care. From a few mails earlier, you also said:
But sudo doesn't change my environment. su does.
So either SUSE changes something, or it does not change your environment. You got to pick one and stop giving people a run-around. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Jan Engelhardt wrote:
Defaults were to keep the environment -- suse changes that.
Well, if you would rather like to have a security issue... see if I care.
If it is a security issue, why is it that only Suse has patched the defaults?
From a few mails earlier, you also said:
But sudo doesn't change my environment. su does.
So either SUSE changes something, or it does not change your environment. You got to pick one and stop giving people a run-around.
A sole purpose of such answers is to point out to readers of our mail list archives that it is not problem with openSUSE setup, but with your customization.
It's suse that is customizing standard utils not to work in standard ways. My "customizations", as you call them, are to try to get back to standard functionality.
You are playing games. I said: 1) sudo doesn't change my environment. 2) Then Raijko said: 3) To which I said: 4) To which you challenged me to show SuSE's customizations that I had to work around so my "sudo wouldn't change the environment" 5) Which I did. --- I fixed my sudo to work as it used to work. I now find that "su" is broken -- Independent of sudo. I have no idea why, but given special mods in many or most suse packages that make them operate in non-standard ways, I was inclined to mention the problem here first as it does not comply with documented behavior -- I didn't file it as a bug as I don't know what is causing it. sudo is not at issue for me. I fixed my configuration to suit me. But that is independent of 'su'. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
В Fri, 29 Mar 2013 01:02:01 -0700 Linda Walsh <suse@tlinx.org> пишет:
I now find that "su" is broken -- Independent of sudo.
The only thing you found is that /something/ behaves differently in 12.3. So far you did not show a single evidence that it is "su" fault. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Andrey Borzenkov wrote:
В Fri, 29 Mar 2013 01:02:01 -0700 Linda Walsh <suse@tlinx.org> пишет:
I now find that "su" is broken -- Independent of sudo.
The only thing you found is that /something/ behaves differently in 12.3. So far you did not show a single evidence that it is "su" fault.
I see evidence that the 'su' that was last installed on my system was from core utils. in version 8.17 -- I also see it was removed from core utils in 8.18 and moved to util-linux (so it says in the coreutils 8.21 in factory) But rpm thinks I have 8.17 installed... hmmmm... So where is the 'su' in factory? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Linda Walsh <suse@tlinx.org> [03-29-13 05:47]: [...]
I see evidence that the 'su' that was last installed on my system was from core utils. in version 8.17 -- I also see it was removed from core utils in 8.18 and moved to util-linux (so it says in the coreutils 8.21 in factory)
But rpm thinks I have 8.17 installed... hmmmm...
So where is the 'su' in factory?
rpm -qf `which su` -- (paka)Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 http://en.opensuse.org openSUSE Community Member Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
В Fri, 22 Mar 2013 10:06:55 -0700 Linda Walsh <suse@tlinx.org> пишет:
Now, sudo has an option that can shortcut that, but old habits have me typing in sudo su about 70% of the time, But that's resetting key variables (majority are NOT changed)...
LS_OPTIONS & PATH
PS1 REMOTEHOST DISPLAY
Neither of these are touched by su with or without "-p". -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Andrey Borzenkov wrote:
В Fri, 22 Mar 2013 10:06:55 -0700 Linda Walsh <suse@tlinx.org> пишет:
Now, sudo has an option that can shortcut that, but old habits have me typing in sudo su about 70% of the time, But that's resetting key variables (majority are NOT changed)...
LS_OPTIONS & PATH
PS1 REMOTEHOST DISPLAY
Neither of these are touched by su with or without "-p".
They weren't on 12.1 nor on 12.2 But they are on 12.3 and factory -- something is resetting them -- I'd say...maybe a change to one of the pam files that calls pam_env.so as it can set / reset them. Both sudo and su now reset my PS1 to a less secure prompt. Before, my prompt set the user@host:fullpath in the titlebar. Interestingly -- sudo bash -- still works: sudo bash User root's .bashrc called 2nd time Ishtar:/etc# echo $PS1 \[$(titlebar)\]${HOSTNAME}:$(spwd "$PWD")#\[\] Ishtar:/etc# exit Ishtar:/etc> sudo su User root's .bashrc called 2nd time etc# echo $PS1 \[\]$(spwd "$PWD" )#\[\] But going through 'su' resets PS1 -- including if I go through su -c bash. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
В Thu, 28 Mar 2013 17:47:16 -0700 Linda Walsh <suse@tlinx.org> пишет:
Andrey Borzenkov wrote:
В Fri, 22 Mar 2013 10:06:55 -0700 Linda Walsh <suse@tlinx.org> пишет:
Now, sudo has an option that can shortcut that, but old habits have me typing in sudo su about 70% of the time, But that's resetting key variables (majority are NOT changed)...
LS_OPTIONS & PATH
PS1 REMOTEHOST DISPLAY
Neither of these are touched by su with or without "-p".
They weren't on 12.1 nor on 12.2
But they are on 12.3 and factory -- something is resetting them
So check your startup files where these variables are set and whether the same startup files are executed in both cases. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Andrey Borzenkov wrote:
В Thu, 28 Mar 2013 17:47:16 -0700 Linda Walsh <suse@tlinx.org> пишет:
Andrey Borzenkov wrote:
Linda Walsh <suse@tlinx.org> пишет:
su is resetting key variables (majority are NOT changed): LS_OPTIONS & PATH PS1 REMOTEHOST DISPLAY
Neither of these are touched by su with or without "-p".
They weren't on 12.1 nor on 12.2
But they are on 12.3 and factory -- something is resetting them
So check your startup files where these variables are set and whether the same startup files are executed in both cases.
Startup files don't set them. pam_env.so sets them. It hasn't changed. pamstack for su config hasn't changed: #%PAM-1.0 auth sufficient pam_rootok.so auth include common-auth account sufficient pam_rootok.so account include common-account password include common-password session include common-session session optional pam_xauth.so and common-session has the call to pam_env.so: # session optional pam_env.so session sufficient pam_winbind.so session required pam_limits.so session required pam_unix.so try_first_pass session optional pam_umask.so I'd suggest possibility of pam_env.so changing, BUT it seems like it would affect more programs as it's called in every session reference -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tuesday 2013-04-02 20:34, Linda Walsh wrote:
# session optional pam_env.so session sufficient pam_winbind.so session required pam_limits.so session required pam_unix.so try_first_pass session optional pam_umask.so
I'd suggest possibility of pam_env.so changing, BUT it seems like it would affect more programs as it's called in every session reference
So, pull pam_env.so out and see what happens. Then you know what pam_env does, or what it does not. (A look in the manpage also explains what it is going to do.) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Jan Engelhardt wrote:
On Tuesday 2013-04-02 20:34, Linda Walsh wrote:
# session optional pam_env.so session sufficient pam_winbind.so session required pam_limits.so session required pam_unix.so try_first_pass session optional pam_umask.so
I'd suggest possibility of pam_env.so changing, BUT it seems like it would affect more programs as it's called in every session reference
So, pull pam_env.so out and see what happens. Then you know what pam_env does, or what it does not. (A look in the manpage also explains what it is going to do.)
--- You mean out of the config for 'su' --- copy the common into su sans pam_env? Cuz pam_env is what sets them correctly when I log in in the first place. Right?...(going on that assumption)... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Linda Walsh wrote:
Jan Engelhardt wrote:
Right?...(going on that assumption)...
Bingo. Ishtar:/etc/pam.d> sudo su User law's .bashrc called 2nd time Ishtar:etc/pam.d# echo $DISPLAY athenae:0 ---- /etc/common.session in 12.3+factory: session required pam_limits.so session required pam_unix.so try_first_pass session optional pam_umask.so session optional pam_env.so /etc/common.session in 12.2: session required pam_limits.so session required pam_unix2.so session optional pam_umask.so -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Bug 813074 Submitted -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 04/02/2013 02:34 PM, Linda Walsh wrote:
Andrey Borzenkov wrote:
В Thu, 28 Mar 2013 17:47:16 -0700 Linda Walsh <suse@tlinx.org> пишет:
Andrey Borzenkov wrote:
Linda Walsh <suse@tlinx.org> пишет:
su is resetting key variables (majority are NOT changed): LS_OPTIONS & PATH PS1 REMOTEHOST DISPLAY
Neither of these are touched by su with or without "-p".
They weren't on 12.1 nor on 12.2
But they are on 12.3 and factory -- something is resetting them So check your startup files where these variables are set and whether the same startup files are executed in both cases.
Startup files don't set them. pam_env.so sets them.
To be a little bit more correct, pam_env.so doesn't set them either but after su completes, /etc/profile is re-read. which also re-reads /etc/profile.d/* and changes LS_OPTIONS and PATH based on your new uid. you can test it by commenting line 27 of /etc/profile.d/ls.bash out or adding FOO='bar' under it. after your new su session you will see a difference. i can only assume that if /etc/profile is being source again, other shell startup files are also re-sourced. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
llua wrote:
On 04/02/2013 02:34 PM, Linda Walsh wrote:
Startup files don't set them. pam_env.so sets them.
To be a little bit more correct, pam_env.so doesn't set them either but after su completes, /etc/profile is re-read.
Not unless it is a acting as a login shell (if '-' or '-l' was specified. Otherwise it's to act like a normal instance of a new shell -- as if you typed 'bash'. That's mostly fine, since my bashrc_local is run after bashrc and configures specifics for my system. Really. pam_env DOES set them:
From my pam_env.conf: # # First, some special variables # # Set the REMOTEHOST variable for any hosts that are remote, default # to "localhost" rather than not being set at all #REMOTEHOST DEFAULT=localhost OVERRIDE=@{PAM_RHOST} REMOTEHOST DEFAULT="" OVERRIDE=@{PAM_RHOST} # # Set the DISPLAY variable if it seems reasonable DISPLAY DEFAULT=${REMOTEHOST}:0.0 OVERRIDE=${DISPLAY}
That's the only place they are set because only your initial log authorization to the system has the remote-host value for PAM to propagate into your environment. Since 'sudo' is not something used to log into the system from another system, it should never be tampering with REMOTEHOST/DISPLAY. Only programs guarding initial authorization to access the machine know where you are logging in *from*. They are responsible for setting REMOTEHOST/DISPLAY if needed, which are propagated into the environment. Removing those in the middle of a login session can have your program displays come upon another terminal or display in front of someone else.... i.e. its a potential data privacy issue and by extension, a security issue. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (11)
-
Andrey Borzenkov -
Carlos E. R. -
Claudio Freire -
Guido Berhoerster -
Jan Engelhardt -
Ken Schneider - openSUSE -
Linda Walsh -
llua -
Patrick Shanahan -
Peter Hanisch -
Rajko