Su Path Hard Coded?

Home » CentOS » Su Path Hard Coded?
CentOS 20 Comments

Is there any way of changing the PATH that’s set by ‘su’ to be specific to my needs? It looks like ‘su’ has the path’s hard coded.

% rpm -qf /bin/su coreutils-5.97-34.el5_8.1

% strings /bin/su | grep local.bin
/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
/usr/local/bin:/bin:/usr/bin

I could kludge it with pam_env, I guess, but that may have more impact than just ‘su’ and I’d like to avoid side-effects.

Thanks!

20 thoughts on - Su Path Hard Coded?

  • But it should be executing the target user’s .profile which can override it. ‘-‘ should be a synonym for -l or –login.

  • You’ve missed the point. I want the ability to set the default path on
    ‘su -‘ to be /bin:/usr/bin and then let the users override if they wish. I do not want the default path to be /usr/local/bin:/bin:/usr/bin

  • Idiots in other teams breaking things :-(

    That’s never a reasonable solution for an enterprise distro; what happens at the next “yum update”? :-)

    If the answer is “it’s hard coded; nothing you can do” then I guess I’ll have to live with it. I’m hoping, though, that there’s a better solution :-)

  • The reasonable solution is to live with the defaults…

    Hmmm, per ‘man su’ on a debian system, you can override with ENV_PATH
    (default /bin:/usr/bin) or (for root) ENV_SUPATH (default
    /sbin:/bin:/usr/sbin:/usr/bin) /etc/login.defs. Adding
    /usr/local/bin must be an RH-specific patch.

  • Have you tried changing the setting for secure_path in /etc/sudoers?
    The manpage for “sudoers” has some more info about this.

  • Stephen Harris writes:

    Silly question but what are you actually trying to accomplish? Restricting the path doesn’t restrict what people can run. Not having having /usr/local/bin in the path doesn’t stop someone from giving the full path to the program or cd-ing to /usr/local/bin and running something there with ./progName.

    Once a user has become root, they own the system. You really can’t restrict them at that point. If you don’t want them doing some things, perhaps su isn’t the best solution.

    Cheers, Dave

  • David G. Miller wrote:
    having things, perhaps su isn’t the best solution.

    Good point, Dave. Stephen – are you sure you don’t want to give them sudo, with limits as to what commands they can run?

    mark

  • Or if the real issue is shared use of a machine with some conflicts of interest, giving different users or groups their own VM’s might be a better solution than trying to play referee.

  • I want the ability to “set the default path”. That’s all. Just so that when I do “su – foobar” then the path defaults to /bin:/usr/bin. If foobar wants to add /usr/local/bin then foobar decides. If I decide I want the default path to be /myspecial/bin:/bin:/usr/bin (so that all my users get this, by default) then I can.

    Just “set the default path”. Nothing more, nothing less.

  • Who says all my users run “/bin/sh” or “/bin/bash” as their shell?
    Do I need to need to handle /etc/csh.login? And what about non-standard shells?

    /etc/profile is a kludge; it’s not a solution. A kludge may be all I can do. But… *sigh*

  • That isn’t your problem. It’s the solution you’ve come up with for your problem.

    What is the *problem* that removing /usr/local/bin from the default path is supposed to fix? What actual impact does it have on you if you
    *don’t* change it?

    If it is just a matter of “you don’t like it”, perhaps you should leave it alone. Changing configurations from the defaults in a way that requires additional work to maintain on the long term for no clear payoff is just wasting time and asking for mysterious breakages in the future when people who expect the system to work the way the vendor normally configures it run into your customizations without warning.

    But if it is actually causing a *problem*, present the problem itself. There may be other ways to address it you haven’t thought of but others here may have used or can propose.

  • S> I want the ability to “set the default path”. That’s all.

    J> set it in /etc/profile then. that gets run on su -l $someuser

    S> Who says all my users run “/bin/sh” or “/bin/bash” as their shell? Do I
    S> need to need to handle /etc/csh.login? And what about non-standard S> shells?

    It sounds like your best bet would be to change the source for su, and
    just be prepared to reinstall it if/when yum (or whatever) replaces it.

    Being able to specify the default PATH without having to mess with shell
    setup files is a nice feature; Solaris allows you to do this by providing
    an /etc/default/su file to set the PATH plus other things like whether you
    want to use syslog for access logging, etc.

    Why not change the production version to use (say) /etc/sysconfig/su for
    the default PATH? This way any admin can tweak su behavior to suit
    themselves without messing with the code, especially critical code like
    this.

  • Yeah, that’s the functionality I was hoping to be able to replicate. Seems like an odd RedHat restriction, especially since other Linux variants can do this via login.defs. Ah well.

    I guess I’ll have to live with it.

    Thanks!

  • I see you are running CentOS 5. Perhaps have a look at

    /etc/security/pam_env.conf

    Does setting the default PATH there have any effect?

    Kal

LEAVE A COMMENT