sh

[Alain St-Laurent]

the answers regarding sh and root
are very interesting but I still
have questions regarding regular users.

our passwd file shows different ways
to the shell.

root...:/sbin/sh
...:/bin/sh
...:/sbin/sh
...:/usr/bin/sh

they don't seem to be the same

-r-xr-xr-x 2 bin bin 499712 Oct 20 1998 /usr/bin/sh

-r-xr-xr-x 2 bin bin 499712 Oct 20 1998 /bin/sh

-rwxrwxrwx 1 bin bin 389120 Oct 20 1998 /sbin/sh


most of the users have /sbin/sh
a few have /bin/sh

is that ok ?
which is best ?

[Sanjay_6]

Hi,

The system id such as root, daemon, lp should be /sbin/sh. The user id should have /usr/bin/sh.

Hope this helps.

Regds

[Kent Ostby · Accepted solution]

/bin/sh is a symbolic link to /usr/bin/sh.

/sbin/sh should be used primarily for root users since it is only necessary when /usr cannot be mounted.

The permissions on /sbin/sh should be 555.

You would need to run either:

chmod 555 /sbin/sh
or
chmod 555 /sbin/sh
on your system to correct the permissions.

The way you have things right now, someone could modify /sbin/sh and put in a hacker program in its place since they have write permission.

[Elmar P. Kolkman]

/bin/sh == /usr/bin/sh. That is no problem. They can use shared libraries and those are available when normal users log in. But root needs a statically linked shell, since root can login when nothing apart from / (containing /sbin) is mounted, such as LVM maintenance mode. And that is waht /sbin/sh is. A statically linked, smaller, shell.

But there is a major security problem on your system. /sbin/sh shouldn't be world-writable!!!
And normally /sbin/sh is smaller as the /bin/sh and /usr/bin/sh, not smaller as on your system. What OS version are you using?

[Elmar P. Kolkman]

Oops, I think I made a mess of the smaller/larger info.

/sbin/sh is normally larger as the other shells, because it is statically linked, not smaller.

I think running file /sbin/sh might be interesting, to say the least...

[Patrick Wallek]

/sbin/sh is REQUIRED for the root account. The reason is that /usr/bin is not available during the boot process and root must be able to do things with the shell. This is also required when booting to single-user mode. In single-user mode You only have the / directory mounted so only /sbin/sh is available.

Now /bin and /usr/bin are the same directory. If you do an 'll /bin' you will notice that it is a link to /usr/bin. Anything that you use /bin for you should really use /usr/bin. It is possible that the /bin link may go away someday.

Typically any of the commands in /sbin are statically linked binaries, or StaticBINary, or sbin. Again, these are used when the libraries in /usr are not available (ie. boot-up or single-user mode).

Now one thing that does worry me is the difference between your /usr/bin/sh and /sbin/sh. Typically commands in /sbin are larger than in /usr/bin because of the library issue. You don't say what version of HP-UX this is, but here are some of my sh shells.

10.20
# ll /usr/bin/sh /sbin/sh
-r-xr-xr-x 1 bin bin 401408 Dec 2 2002 /sbin/sh*
-r-xr-xr-x 2 bin bin 491520 Dec 2 2002 /usr/bin/sh*

11.0
# ll /usr/bin/sh /sbin/sh
-r-xr-xr-x 1 bin bin 421888 Apr 23 2001 /sbin/sh*
-r-xr-xr-x 2 bin bin 221184 Apr 23 2001 /usr/bin/sh*

11.11
$ ll /usr/bin/sh /sbin/sh
-r-xr-xr-x 1 bin bin 405504 Feb 11 2003 /sbin/sh
-r-xr-xr-x 2 bin bin 208896 Feb 11 2003 /usr/bin/sh

If you notice, all the /sbin/sh files are larger. I would also change the permissions on your /sbin/sh to -r-xr-xr-x (555). There is not reason whatsoever to have that file be writeable.

[Alain St-Laurent]

Wow !!! Thanks for the fast responses.

I changed the permissions on sbin/sh

should I change the shell reference
in passwd of all my regular users to

...:usr/bin/sh

???

[Kent Ostby]

The only benefit to doing that is that you will have consistency should anything change in the future.

It wont hurt either way.

[Alain St-Laurent]

in response to your inquiry about
the version I'm running

# ll /usr/bin/sh /sbin/sh
-r-xr-xr-x 1 bin bin 389120 Oct 20 1998 /sbin/sh
-r-xr-xr-x 2 bin bin 499712 Oct 20 1998 /usr/bin/sh
# uname -a
HP-UX lacasse B.10.20 U 9000/879 445631361 unlimited-user license

[Patrick Wallek]

Since this is 10.20 you should be OK with those shells. I noticed after I posted that on my 10.20 machine that /usr/bin/sh IS larger than /sbin/sh. That seems a bit strange to me but it is apparently correct.

As said, you could change all /bin to /usr/bin if you like. At this point they are the same. If you are going to stay on 10.20 on this machine and never upgrade it, I wouldn't worry too much.

[Mike Stroyan]

You should use /usr/bin/sh instead of /bin/sh. The default list of legal user shells has /usr/bin/sh but does not have /bin/sh. See "man getusershell". If a user's shell is not in the default list or listed in /etc/shells, then that account won't be able to ftp into the system.

[Bill Hassell]

For consistency, all the users that have the POSIX shell /bin/sh should be changed to /usr/bin/sh. This is the default shell location. As mentioned. /bin/sh does not exist! Instead, it is a link to the 'real' location and may go away someday (although that has been said for almost 10 years now). The industry standard for SysV V.4 filesystem layout removes the old /bin and /lib directories and moves them to /usr/bin and /usr/lib respectively.

Since /sbin/sh is statically linked, the executables will not use shared libraries, thus increasing the amount of RAM for each /sbin/sh instance. Not a lot of RAM but for dozens to hundreds of users, this might be somewhat important.

And as mentioned, /sbin/sh size looks very wrong. Perhaps it has been hacked. Use the file command to look at it:

# file /sbin/sh
/sbin/sh: PA-RISC1.1 shared executable
# file /usr/bin/sh
/usr/bin/sh: PA-RISC1.1 shared executable dynamically linked

The "dynamically linked" indicates that this program uses shared libraries. I would NOT trust /sbin/sh, especially because it had 777 permissions. Any file or directory with 777 is a huge security risk and you cannot trust the contents of those files or directories. Get a clean version of /usr/bin/sh from another machine or patch the POSIX shell to the latest version and you'll get new executables. I would perform a security check for world-writable permissions, expecially in /sbin and /usr/bin:

find /sbin /usr/bin -perm -002 -exec ll {} \;

This command MUST return nothing. If it shows and files or directories, they must be assumed to be corrupt and either an intruder or a very bad sysadmin has messed with your system. I would also include /etc in the list to be scanned.

[D Block 2]

I believe when you use SAM to create users, you have a slection of choices. I'm not sure if /sbin/sh is a default option.

which brings to mind, have you ever booted an HPUX kernel in Maintenance mode before and notice the shell it boots ? you dont' have acces to the editor vi or ed. I don't belive you can even mount afile system.

the point is. there are many shells including booting the kernel in maintenance mode.

[Bill Hassell]

Just to clarify: /sbin/sh runs in single user mode, /usr/bin/sh does not since /use is not mounted. However, you can mount the required directories in single user mode (there is /sbin/mount). In single user mode, to use vi or other tools not found in /sbin, just mount these:

mount /usr
mount /var
mount /tmp

[Alain St-Laurent]

thank you for your security concerns

that system as no outside access
and is relatively secure.

maybe a former administrator changed
the access rights.

the file command gives the folowing info...

#
# file /sbin/sh
/sbin/sh: PA-RISC1.1 shared executable
# file /usr/bin/sh
/usr/bin/sh: PA-RISC1.1 shared executable dynamically linked
#