I am using Tumbleweed but I am not upgrading it very often this days because of daily load is very high. Recently, I found commands in /usr/local/bin, where my custom installed apps locate, cannot be used in su or sudo environment unless I give it the full path, such as /usr/loca/bin/dislocker.
This problem might occur in the last 2 months. It used to work fine.
Anyone know what is the problem? Any solution to this?
Yes, it should work. But it did not. So I am confused.
I seldom use su -. Here is the output,
cnzhx@ot:~> su -
Password:
ot:~ # echo $PATH
/sbin:/usr/sbin:/usr/local/sbin:/root/bin:/usr/local/bin:/usr/bin:/bin:/usr/lib/mit/sbin
ot:~ # which dislocker
/usr/local/bin/dislocker
ot:~ # exit
logout
It looks like the /usr/local/bin is still in this environment. But this time, the which can find dislocker.
So the problem is, /usr/local/bin is also in su’s $PATH, why does which not find dislocker there?
Am I the only one who get this weird problem? If that is it, maybe I have touched something I do not know. Actually, I am too busy to perform such actions during this period. But I am not so sure. Any idea how to get it right?
On 05/16/2018 10:16 AM, cnzhx wrote:
>
> nrickert;2865622 Wrote:
>> With those PATH settings, it should be working.
>
> Yes, it should work. But it did not. So I am confused.
>
> nrickert;2865622 Wrote:
>>
>> If you try:
>>>
> Code:
> --------------------
> > >
> > su -
> > echo $PATH
> > exit
> >
> --------------------
>>>
>> you may get a different path. With the “-” argument to “su” the path
>> is reset. Perhaps that’s where you are having issues.
> I seldom use su -. Here is the output,
>
> Code:
> --------------------
> cnzhx@ot:~> su -
> Password:
> ot:~ # echo $PATH
> /sbin:/usr/sbin:/usr/local/sbin:/root/bin:/usr/local/bin:/usr/bin:/bin:/usr/lib/mit/sbin
> ot:~ # which dislocker
> /usr/local/bin/dislocker
> ot:~ # exit
> logout
> --------------------
>
> It looks like the /usr/local/bin is still in this environment. But
> this time, the which can find dislocker.
>
> So the problem is, /usr/local/bin is also in su's $PATH, why does
> which not find dislocker there?
>
> Am I the only one who get this weird problem? If that is it, maybe I
> have touched something I do not know. Actually, I am too busy to perform
> such actions during this period. But I am not so sure. Any idea how to
> get it right?
>
>
Does ‘dislocker’ have the execute bit set?
–
Ken
linux since 1984
S.u.S.E./openSUSE since 1996
The symlink permissions are not the ones that count; what ownership
permissions do you have on the target file?
ls -l /usr/local/bin/dislocker*
As a note while verifying/testing this, if your symlink is broken it will
also not show up in ‘which’ output, which is what you would expect.
Symlinks always have all bits set, even though they do not necessarily get
accessed by everybody.
If your dislocker-fuse executable is user-owned by ‘root’, and then that
user does not have execute rights, but the group-owner and/or other users
have execute, then that would explain what you are seeing. Also note that
FACLs could come into play. We’ll see what the output above shows, though.
–
Good luck.
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.
If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.
But I think I should add some thoughts here because I think we are chasing the wrong direction. Like the problem with dislocker, other bash scripts, e.g. za ( a script I made to do some regular stuff and being put inside ~/bin) used to work after su. They now do not work as well. So I think the problem is not only on dislocker but with the system. The same symptom as dislocker.
But I think I should add some thoughts here because I think we are chasing the wrong direction. Like the problem with dislocker, other bash scripts, e.g. za ( a script I made to do some regular stuff and being put inside ~/bin) used to work after su. They now do not work as well. So I think the problem is not only on dislocker but with the system. The same symptom as dislocker.
We have to eliminate the known possible causes of what you are describing, before we can hope to find what is going wrong.
I’ll try to think some more about this before I reply again.
Well, no hurry. I do not use this method too often, anyway. I am just curious it seems no bug report on this or any discussion on the mailing list. Thanks for looking into this.
I have only root and home partitions. But there is a BtrFS subvolume mount point in /etc/fstab regarding this. It looks like,
Thank you, wolfi323. This must be the problem. I checked the file,
# cat /etc/default/su
# Per default, only "su -" will set a new PATH.
# If this variable is set to "yes" (default is "no"),
# every su call will overwrite the PATH variable.
#
# The recommended default is "yes". The default "no" behavior could have
# a security implication in applications that use commands without path.
ALWAYS_SET_PATH=yes
# Default path.
PATH=/usr/local/bin:/bin:/usr/bin
# Default path for a user invoking su to root.
SUPATH=/usr/sbin:/bin:/usr/bin:/sbin
So, /usr/local/bin is not in the SUPATH.
But given that setting ALWAYS_SET_PATH default to “no” could cause security problems, I append the /usr/local/bin to the SUPATH definition. Hopefully after a reboot the problem will be gone. I will report back after a reboot (not now, maybe this weekend).
I guess this is not a good way to use su. Or why there is only me who run into this problem ;(
On 05/17/2018 05:26 AM, cnzhx wrote:
>
> wolfi323;2865705 Wrote:
>> “su” doesn’t use $PATH by default since a little more than a month (for
>> security reasons I suppose).
>> Welcome - openSUSE Build Service
I think you mean that the $PATH is not inherited from the calling user;
every user uses PATH for sure. I only mention this to try to be clear for
others who may not understand what PATH is and why it is used, i.e. newbies.
>> Have a look at /etc/default/su .
>>
>> sudo’s path can be set in /etc/sudoers .
>
> Thank you, wolfi323. This must be the problem. I checked the file,
I thought you had verified, while running as ‘root’, that your PATH
variable DIS include the desired path. Did I misread something? While
you are ‘root’ run:
echo ${PATH}
It may not inherit a given directory from the sudo-ing user, but it can
still be set to whatever you want.
I guess this is not a good way to use su. Or why there is only me who
> run into this problem ;(
I do not think most people even have things in /usr/local/bin, much less
need to use them as ‘root’. Most executables, especially those running as
‘root’, live in more-default places like /usr/sbin/, /sbin/, /usr/bin, etc.
–
Good luck.
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.
If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.
Thanks. I do not completely understand $PATH, for example
For me, the whole story looks like this, (But I am not sure whether things changed after the morning’s upgrade and the change I made to the /etc/default/su file; I havn’t reboot since the change of the config file.)