"which" cannot find command in /usr/local/bin in su or sudo

Hello everyone,

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?

TIA
Haoxian

What’s the output from:


echo $PATH
sudo echo $PATH

Thank you, nrickert,

The outputs are,

cnzhx@ot:~> echo $PATH
/home/cnzhx/bin:/usr/local/bin:/usr/bin:/bin:/usr/lib/mit/sbin:/home/cnzhx/anaconda3/bin:/home/cnzhx/anaconda3/bin
cnzhx@ot:~> sudo echo $PATH
[sudo] password for root:
/home/cnzhx/bin:/usr/local/bin:/usr/bin:/bin:/usr/lib/mit/sbin:/home/cnzhx/anaconda3/bin:/home/cnzhx/anaconda3/bin/

And I do not remember I have done anything related to she $PATH.

With those PATH settings, it should be working.

If you try:


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.

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

Thank you, Ken. The dislocker has execute bit set, I think,

# ls -al /usr/local/bin/dislocker
lrwxrwxrwx 1 root root 14 May  6 00:09 /usr/local/bin/dislocker -> dislocker-fuse

I just upgraded from 20180429 to 20180515 snapshot. The problem is still there.

Try:

ls -alL /usr/bin/dislocker

The ‘-L’ tells “ls” to follow the symbolic link.

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.

Think you both. I really didn’t know that :slight_smile:

Here is the new output,

# ls -alL /usr/local/bin/dislocker
-rwxr-xr-x 1 root root 22016 May  6 00:09 /usr/local/bin/dislocker

Is there anything wrong with this then?

Okay. So far so good.

Now try:

ldd /usr/local/bin/dislocker

Maybe there’s a missing dynamic link library.

I am not sure what it does but with or without su beforehand, the results are like follows

cnzhx@ot:~> ldd /usr/local/bin/dislocker
        linux-vdso.so.1 (0x00007ffe8b93f000)
        libfuse.so.2 => /lib64/libfuse.so.2 (0x00007fd450b58000)
        libdislocker.so.0.7 => /usr/local/lib64/libdislocker.so.0.7 (0x00007fd450940000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fd450721000)
        libmbedcrypto.so.1 => /usr/lib64/libmbedcrypto.so.1 (0x00007fd4504c6000)
        libc.so.6 => /lib64/libc.so.6 (0x00007fd450108000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007fd44ff04000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fd450f99000)
ot:/home/cnzhx # ldd /usr/local/bin/dislocker
        linux-vdso.so.1 (0x00007ffef39f0000)
        libfuse.so.2 => /lib64/libfuse.so.2 (0x00007f4ec0e71000)
        libdislocker.so.0.7 => /usr/local/lib64/libdislocker.so.0.7 (0x00007f4ec0c59000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f4ec0a3a000)
        libmbedcrypto.so.1 => /usr/lib64/libmbedcrypto.so.1 (0x00007f4ec07df000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f4ec0421000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007f4ec021d000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f4ec12b2000)

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.

Those look okay.

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.

Another question:

Is “/usr/local/bin” part of the root file system, or is it a separate partition?

If it is a separate partition, can you give us the line from “/etc/fstab” used to mount it?

I’m asking, because it is possible to mount with the “noexec” option, which makes everything on that partition non-executable.

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,

UUID=dd453ace-58d8-42dc-9011-12c929bf45fd /usr/local btrfs subvol=@/usr/local 0 0

It should have no influence on my problem, shouldn’t it?

BTW, when the last time I run into this problem, I have re-installed dislocker. But it does not affect the situation.

That eliminates another possible explanation.

“su” doesn’t use $PATH by default since a little more than a month (for security reasons I suppose).
https://build.opensuse.org/package/rdiff/openSUSE:Factory/util-linux?linkrev=base&rev=228

Have a look at /etc/default/su .

sudo’s path can be set in /etc/sudoers .

Cool!

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

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

cnzhx@ot:~> sudo echo ${PATH}
/home/cnzhx/bin:/usr/local/bin:/usr/bin:/bin:/usr/lib/mit/sbin:/home/cnzhx/anaconda3/bin:/home/cnzhx/anaconda3/bin
cnzhx@ot:~> su
Password:
ot:/home/cnzhx # echo ${PATH}
/sbin:/bin:/usr/sbin:/usr/bin
ot:/home/cnzhx # exit
exit
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:~ #

Now, that’s it. I am a little confused about this. It seems like, sudo echo $PATH just gives the $PATH of current user; but,

cnzhx@ot:~> sudo which dislocker
which: no dislocker in (/usr/sbin:/usr/bin:/sbin:/bin)

So, any command running after sudo uses ${PATH} from su but sudo itself uses ${PATH} of current user. Am I right?

Then, if I use su - instead su, dislocker can be located.

cnzhx@ot:~> su -
Password:
ot:~ # which dislocker
/usr/local/bin/dislocker

I guess this is the way to use something inside /usr/local/bin/ now.

I do not know this. I followed the default method to install dislocker from GitHub. It is there since then.

Thank you, ab, for the clarification.