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 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

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

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

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

On Sat, 23 Mar 2013 18:26:09 -0700 Linda Walsh 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, 24 Mar 2013 16:13:12 -0300 Claudio Freire 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 25/03/13 00:33, Claudio Freire wrote:

On Sun, Mar 24, 2013 at 7:55 PM, Rajko 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

* Claudio Freire [2013-03-25 16:12]:

On Mon, Mar 25, 2013 at 8:36 AM, Peter Hanisch wrote:

...

On 25/03/13 00:33, Claudio Freire wrote:

...

On Sun, Mar 24, 2013 at 7:55 PM, Rajko 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 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

On Friday 2013-03-29 00:51, Linda Walsh wrote:

Rajko wrote:

...

On Sun, 24 Mar 2013 16:13:12 -0300 Claudio Freire 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

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

On Thu, 28 Mar 2013 16:51:52 -0700 Linda Walsh 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 Sun, 24 Mar 2013 16:13:12 -0300 Claudio Freire 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

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

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

Andrey Borzenkov wrote:

В Fri, 29 Mar 2013 01:02:01 -0700 Linda Walsh пишет:

...

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

В Fri, 22 Mar 2013 10:06:55 -0700 Linda Walsh пишет:

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

В Thu, 28 Mar 2013 17:47:16 -0700 Linda Walsh пишет:

Andrey Borzenkov wrote:

...

В Fri, 22 Mar 2013 10:06:55 -0700 Linda Walsh пишет:

...

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

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

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

On 04/02/2013 02:34 PM, Linda Walsh wrote:

Andrey Borzenkov wrote:

...

В Thu, 28 Mar 2013 17:47:16 -0700 Linda Walsh пишет:

...

Andrey Borzenkov wrote:

...

Linda Walsh пишет:

...

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