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!
On Mon, Jul 23, 2012 at 2:00 PM, Stephen Harris lists@spuddy.org wrote:
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.
Can't you use the usual approach of 'su -' to pick up the target user's login environment?
On Mon, Jul 23, 2012 at 2:18 PM, Stephen Harris lists@spuddy.org wrote:
On Mon, Jul 23, 2012 at 02:14:45PM -0500, Les Mikesell wrote:
Can't you use the usual approach of 'su -' to pick up the target user's login environment?
It's "su -" that causes the 'su' comman to rewrite the PATH to the hardcoded default.
But it should be executing the target user's .profile which can override it. '-' should be a synonym for -l or --login.
On Mon, Jul 23, 2012 at 02:33:17PM -0500, Les Mikesell wrote:
On Mon, Jul 23, 2012 at 2:18 PM, Stephen Harris lists@spuddy.org wrote:
On Mon, Jul 23, 2012 at 02:14:45PM -0500, Les Mikesell wrote:
Can't you use the usual approach of 'su -' to pick up the target user's login environment?
It's "su -" that causes the 'su' comman to rewrite the PATH to the hardcoded default.
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
On Mon, Jul 23, 2012 at 2:37 PM, Stephen Harris lists@spuddy.org wrote:
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
Yes, I guess I just wouldn't put things in /usr/local/bin if I didn't want them to be run, so i wouldn't have thought of that... Rebuilding from the src rpm sounds reasonable in that case.
On Mon, Jul 23, 2012 at 02:52:28PM -0500, Les Mikesell wrote:
On Mon, Jul 23, 2012 at 2:37 PM, Stephen Harris lists@spuddy.org wrote:
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
Yes, I guess I just wouldn't put things in /usr/local/bin if I didn't
Idiots in other teams breaking things :-(
want them to be run, so i wouldn't have thought of that... Rebuilding from the src rpm sounds reasonable in that case.
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 :-)
On Mon, Jul 23, 2012 at 3:02 PM, Stephen Harris lists@spuddy.org wrote:
That's never a reasonable solution for an enterprise distro; what happens at the next "yum update"? :-)
The reasonable solution is to live with the defaults...
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 :-)
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.
On Mon, Jul 23, 2012 at 03:31:12PM -0500, Les Mikesell wrote:
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.
AIUI, different versions of su. Those values don't work on RH and downstreams.
On 07/23/2012 10:02 PM, Stephen Harris wrote:
That's never a reasonable solution for an enterprise distro; what happens at the next "yum update"? :-)
You could put your locally modified su into /usr/local/bin :-)
Mogens
On 07/23/2012 02:37 PM, Stephen Harris wrote:
On Mon, Jul 23, 2012 at 02:33:17PM -0500, Les Mikesell wrote:
On Mon, Jul 23, 2012 at 2:18 PM, Stephen Harrislists@spuddy.org wrote:
On Mon, Jul 23, 2012 at 02:14:45PM -0500, Les Mikesell wrote:
Can't you use the usual approach of 'su -' to pick up the target user's login environment?
It's "su -" that causes the 'su' comman to rewrite the PATH to the hardcoded default.
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
Have you tried changing the setting for secure_path in /etc/sudoers? The manpage for "sudoers" has some more info about this.
On Mon, Jul 23, 2012 at 06:16:57PM -0500, Robert Nichols wrote:
On 07/23/2012 02:37 PM, Stephen Harris wrote:
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
Have you tried changing the setting for secure_path in /etc/sudoers? The manpage for "sudoers" has some more info about this.
"su", not "sudo".
Stephen Harris <lists@...> writes:
On Mon, Jul 23, 2012 at 02:33:17PM -0500, Les Mikesell wrote:
On Mon, Jul 23, 2012 at 2:18 PM, Stephen Harris <lists@...> wrote:
On Mon, Jul 23, 2012 at 02:14:45PM -0500, Les Mikesell wrote:
Can't you use the usual approach of 'su -' to pick up the target user's login environment?
It's "su -" that causes the 'su' comman to rewrite the PATH to the hardcoded default.
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
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:
Stephen Harris <lists@...> writes:
On Mon, Jul 23, 2012 at 02:33:17PM -0500, Les Mikesell wrote:
On Mon, Jul 23, 2012 at 2:18 PM, Stephen Harris <lists@...> wrote:
On Mon, Jul 23, 2012 at 02:14:45PM -0500, Les Mikesell wrote:
Can't you use the usual approach of 'su -' to pick up the target user's login environment?
It's "su -" that causes the 'su' comman to rewrite the PATH to the hardcoded default.
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
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.
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
On Tue, Jul 24, 2012 at 1:36 PM, m.roth@5-cent.us wrote:
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.
Good point, Dave. Stephen - are you sure you don't want to give them sudo, with limits as to what commands they can run?
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.
On Tue, Jul 24, 2012 at 04:46:24PM +0000, David G. Miller wrote:
Stephen Harris <lists@...> writes:
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
Silly question but what are you actually trying to accomplish? Restricting the
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.
On 07/24/12 4:33 PM, Stephen Harris wrote:
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.
set it in /etc/profile then. that gets run on su -l $someuser
On Tue, Jul 24, 2012 at 04:43:54PM -0700, John R Pierce wrote:
On 07/24/12 4:33 PM, Stephen Harris wrote:
I want the ability to "set the default path". That's all. Just so that
set it in /etc/profile then. that gets run on su -l $someuser
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*
On 07/24/12 4:33 PM, Stephen Harris wrote:
S> I want the ability to "set the default path". That's all.
On Tue, Jul 24, 2012 at 04:43:54PM -0700, John R Pierce wrote:
J> set it in /etc/profile then. that gets run on su -l $someuser
On Tue, 24 Jul 2012 19:53:23 -0400, Stephen Harris wrote:
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.
On Tue, Jul 24, 2012 at 11:27:09PM -0400, Karl Vogel wrote:
On 07/24/12 4:33 PM, Stephen Harris wrote:
S> I want the ability to "set the default path". That's all.
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.
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!
On 25/07/12 20:10, Stephen Harris wrote:
On Tue, Jul 24, 2012 at 11:27:09PM -0400, Karl Vogel wrote:
On 07/24/12 4:33 PM, Stephen Harris wrote:
S> I want the ability to "set the default path". That's all.
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.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 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
On 07/24/2012 04:33 PM, Stephen Harris wrote:
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.
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.
-
Benjamin Franz -
David G. Miller -
John R Pierce -
Kahlil Hodgson -
Les Mikesell -
m.roth＠5-cent.us -
Mogens Kjaer -
Robert Nichols -
Stephen Harris -
vogelke+centos＠pobox.com