root PATH not coming from /etc/default/login or /etc/default/su
I need to add some directories to root's PATH, so I've been reading up on /etc/default/login and /etc/default/su.
I am at Solaris 10 on a Sun Blade 100.
When I su, my PATH becomes /usr/sbin:/usr/bin
which kind of makes sense (except that the SUPATH= line in /etc/default/su is commented out, and I didn't do it).
But when I login as root, my PATH is set to /usr/sbin:/usr/bin:/usr/openwin/bin:/usr/ucb
Beside the fact that the SUPATH in /etc/default/login also is commented out, it says nothing about the last 2 directories. In fact, the string openwin appears nowhere in any file in /etc/default.
I have also looked for any /.login, /.profile, or similar files that might add openwin to PATH, but I can find nothing.
Does someone know how those last 2 directories get appended to root's PATH in what should be a plain vanilla Solaris 10?
Thanks.
[907 byte] By [
RegExpGuya] at [2007-11-26 17:43:19]
# 1
HiI running solaris 10/6 x86 and have the same problem. roberto
# 2
> But when I login as root, my PATH is set to> /usr/sbin:/usr/bin:/usr/openwin/bin:/usr/ucb
>
Beside the fact that the SUPATH in
> /etc/default/login also is commented out, it says
> nothing about the last 2 directories. In fact, the
> string openwin appears nowhere in any file in
> /etc/default.
How are you logging in? Are you using dtlogin or ssh or what? That process may be modifying the path.
In general you can examine the execution environment for every process all the way back up to init. Use 'pargs -e <PID>'. Start with your shell and work your way up. What's the first process you find without those directories in your path? That process or one of its children modified the PATH. Knowing the process will be additional clues.
--
Darren
# 3
> > But when I login as root, my PATH is set to
/usr/sbin:/usr/bin:/usr/openwin/bin:/usr/ucb
> How are you logging in? Are you using dtlogin or ssh or what? That process may be modifying the path.
I am logging in to a Java Desktop session as root, and from what I read that must be using dtlogin.
> In general you can examine the execution environment
>for every process all the way back up to init. Use
> 'pargs -e <PID>'. Start with your shell and work
> your way up. What's the first process you find
> without those directories in your path?
> Darren
pargs, wow! Even after 25 years I'm still amazed at the vast array of commands available in the Unix world. Amazed, but still confused.
pargs -e on my sh naturally shows the PATH as listed above. The parent process is gnome-terminal and pargs -e on that still shows the long PATH. The parent process of gnome-terminal is init, and there is no PATH for that.
ps -ef shows that dtlogin -daemon is another child process of init, and its PATH is just /usr/sbin:/usr/bin.
I've been looking around the /usr/dt/config directory, but there are no files in there that would add the extra 2 directories to PATH. I also looked at /usr/dt/bin/Xsession, where there at least seem to be uncommented lines that might add /usr/openwin/bin to PATH, but I still don't see anything about /usr/ucb.
Thanks for teaching me something new today, but I'm still in the dark as to how the PATH gets set.
# 4
> pargs, wow! Even after 25 years I'm still amazed at
> the vast array of commands available in the Unix
> world. Amazed, but still confused.
You won't find it on older versions of solaris. There you'd have to rely on /usr/ucb/ps eww <PID>.
> pargs -e on my sh naturally shows the PATH as
> listed above. The parent process is gnome-terminal
> and pargs -e on that still shows the long
> PATH. The parent process of gnome-terminal is init,
> and there is no PATH for that.
Since init does not directly launch gnome-terminal (at least not normally), it is probable that its actual parent has died and is no longer around for us to look at.
The next thing I'd probably do would be to verify that I could stop/start gnome-terminal with 'svcadm' commands.
Then I'd truss the restarter (probably svc.startd) and see if it turned up something useful.
truss -f -e -t exec,fork -p <PID of starter>
Now you can follow the environment as the processes launch. By trimming the output down to exec and fork, it shouldn't be too overwhelming.
--
Darren
# 5
try the following:su -
# 6
> The next thing I'd probably do would be to verify
> that I could stop/start gnome-terminal with 'svcadm'
> commands.
I must confess that I could not figure out the syntax for using svcadm to stop/start gnome-terminal. I could not extrapolate from the man pages' discussion of services such as sendmail and nfs to a seemingly simple program like gnome-terminal.
> Then I'd truss the restarter (probably svc.startd)
> and see if it turned up something useful.
>
> truss -f -e -t exec,fork -p <PID of starter>
>
> Now you can follow the environment as the processes
> launch. By trimming the output down to exec and
> fork, it shouldn't be too overwhelming.
>
Since I can't imagine that anything but the default would be operating, I still tried truss on the PID of svc.startd. I got no results, probably because I started an instance of gnome-terminal from the menu rather than by way of svcadm.
# 7
Since su gives the /usr/sbin:/usr/bin PATH, I wasn't surprised that su - does the same. My impression, though, was that su - root would simulate an actual login as root, and come back with the longer PATH. It did not; perhaps because I wasn't simulating a dtlogin as root?
# 8
Almost certainly. Do you have root SSH enabled? Logging in there should give the same path as su -.-- Darren
# 9
> Do you have root SSH enabled?
If it requires action to enable it, then it must not be enabled. I did try invoking it, and I got messages that the authenticity of the host could not be established, an RSA key fingerprint, and a question if I still wanted to continue connecting. After I answered yes, I got a warning that the host was permanently added to the list of known hosts, and then a password prompt. However, it did not accept my computer's root password.
I truly appreciate your patience, but I have to wonder if we're overthinking this? Given that I haven't intentionally changed root's PATH, I must be experiencing some kind of Solaris default behavior. Shouldn't that be a known property of the OS?
Thanks again.
# 10
HiI booted in comand line mode and my customized root path works fine.My customized path not works in a gnome terminal and ssh session (from a remote host), when I change to root using "su" or "su -" roberto
# 11
> > Do you have root SSH enabled?
>
> If it requires action to enable it, then it must not
> be enabled. I did try invoking it, and I got messages
> that the authenticity of the host could not be
> established, an RSA key fingerprint, and a question
> if I still wanted to continue connecting. After I
> answered yes, I got a warning that the host was
> permanently added to the list of known hosts, and
> then a password prompt. However, it did not accept my
> computer's root password.
Root access may not be inabled in the sshd.conf file. Is 'PermitRootLogin' set to 'yes'? If it is, I can't think of any reason that your login would be denied.
> I truly appreciate your patience, but I have to
> wonder if we're overthinking this? Given that I
> haven't intentionally changed root's PATH, I must be
> experiencing some kind of Solaris default behavior.
> Shouldn't that be a known property of the OS?
Sure, but I don't know what it is off the top of my head or where it might be in the documentation. Since no one else chimed in with the answer I was just giving you some suggestions to track it down yourself.
--
Darren
# 12
> Sure, but I don't know what it is off the top of my head or where it might be in the
> documentation. Since no one else chimed in with the answer I was
> just giving you some suggestions to track it down yourself.
And don't think I don't appreciate it. I really do.
> Root access may not be inabled in the sshd.conf file. Is 'PermitRootLogin' set to 'yes'?
It was not, so I changed it to yes.
> If it is, I can't think of any reason that your login would be denied.
Even after changing it to yes, my password was still rejected. I even tried changing it temporarily to without-password, but I was still prompted and rejected.
I also tried something else yesterday after my last post. I speculated that if the SUPATH in /etc/login wasn't commented out, then maybe it would prevail over the default. But, uncommenting it had no effect. I suppose I could try adding dir5 in /etc/login to see if PATH becomes /usr/sbin:/usr/bin:dir5:/usr/openwin/bin:/usr/ucb.
Maybe it's a coincidence, but there seems to have been an unwanted side effect from my SSH experiments. Every night, I use lynx -auth=id:pw -dump ...
to query the status page of my firewall/router to see if my external IP address changed. That worked for years without any problem, until last night. Now, I get messages that lynx is being denied because it is trying to access without authorization.
Could that have anything to do with the messages yesterday about "permanently adding host to the list of known hosts?" If yes, is there any easy way to undo that?
Thanks again.
# 13
> > Sure, but I don't know what it is off the top of my
> head or where it might be in the
> > documentation. Since no one else chimed in with the
> answer I was
> > just giving you some suggestions to track it down
> yourself.
>
> And don't think I don't appreciate it. I really do.
>
> Root access may not be inabled in the sshd.conf
> file. Is 'PermitRootLogin' set to 'yes'?
>
> It was not, so I changed it to yes.
You have to restart the sshd daemon to make any changes in sshd_config take effect.
> If it is, I can't think of any reason that your login
> would be denied.
>
> Even after changing it to yes, my password was still
> rejected. I even tried changing it temporarily to
> without-password, but I was still prompted and
> rejected.
'without-password' doesn't keep an ssh client from prompting you for a password. It just means that any attempt at a password login will fail. Only non-password logins (like key exchange) will succeed.
> I also tried something else yesterday after my last
> post. I speculated that if the SUPATH in /etc/login
> wasn't commented out, then maybe it would prevail
> over the default. But, uncommenting it had no effect.
> I suppose I could try adding dir5 in
> /etc/login to see if PATH becomes
> /usr/sbin:/usr/bin:dir5:/usr/openwin/bin:/usr/u
> cb.
>
> Maybe it's a coincidence, but there seems to have
> been an unwanted side effect from my SSH experiments.
> Every night, I use lynx -auth=id:pw -dump
> ...
to query the status page of my
> firewall/router to see if my external IP address
> changed. That worked for years without any problem,
> until last night. Now, I get messages that lynx is
> being denied because it is trying to access without
> authorization.
>
> Could that have anything to do with the messages
> yesterday about "permanently adding host to the list
> of known hosts?" If yes, is there any easy way to
> undo that?
No. That's an ssh thing. It's unrelated to any process that doesn't use ssh.
I don't see how a lynx/web authorization issue would be associated with anything you've tried.
--
Darren
