Path issues with root

Rocky Linux Tech Help
1

Having issues running mkfs from root without using the su (or sudo) command which was never an issue on CentOS 7. I know the problem here is my path, but I can’t for the life of me figure out the fix, or why this is different from CentOS 7. I’m sure this is something simple, but everything I’ve tried does not work.

I’m using telnet to connect to a Rocky Linux 9 server using the Rocket D3 Database that runs my application. My application occasionally needs to run a Linux command. When I get to the command line my prompt is:

sh-5.1#

If I run whoami
I get root

If I run id
I get uid=0(root) gid=0(root) groups=0(root)

If I echo $PATH
I get /usr/local/bin:/usr/bin

If I run /sbin/mkfs -t ext3 /dev/sdb1
I get mkfs: failed to execute mkfs.ext3: No such file or directory

Now, the problem is that mkfs is in /sbin/ so clearly it won’t run with that path. The moment I type in su at the sh-5.1# prompt, I get to an actual root prompt and the path/groups change.

If I run whoami
I still get root

If I run id
I get uid=0(root) gid=0(root) groups=0(root),4(adm)

If I echo $PATH
I get /usr/local/sbin:/root/.local/bin:/root/bin:/sbin:/usr/local/sbin:/usr/local/bin:/usr/bin

If I run /sbin/mkfs -t ext3 /dev/sdb1 it works fine.

The issue here is that my application software would require a huge rewrite to find every situation in which I need to access /sbin/. It is much easier to simply give the /sbin/ permissions to root which it should already have… and technically already does. So, I’m confused as to how to change this. I tried exportPATH=/sbin:$PATH but had no luck.

I’m confused as to how the same “user” can have two different paths and two different groups. I realize that I could probably spend a lifetime learning everything about $PATH, environment, profiles, bashrc, etc. so I’m hoping someone who already has the knowledge can impart some wisdom here as to how to correct the path.

2

What is the output of rpm -V rootfiles?

3

Well, I suppose the wisdom is, do not use telnet, use ssh instead. Telnet is very insecure, it sends usernames and passwords as plain text, I also think that while you may be connecting as ‘root’, you do not actually get root. I suggest you ‘ssh’ as a normal user and run commands remotely with sudo.

1 Like
4

The fact that you’ve installed and configured telnet-server for root logins is scary to say the least. You really should be using ssh instead. At any rate this is going to be an issue with the way that telnet-server performs logins and I’m not about to install and test it on my own servers to find out what it is. See if you can reproduce the issue with ssh and if so we can troubleshoot from there.

…and get rid of telnet-server. I can’t think of a single reason to use it.

5

The telnet server is just used locally to connect directly to the database, no port forward in the router, no WAN access. SSH gives too much power to the end user. We cannot protect them from themselves if they have direct access to the Linux command line, been down that road several times.

Sure, sniffing is a concern with telnet, but that assumes local access via WiFi is open or available.

I’ll try rpm -V rootfiles next time I have access to the system.

6

What? How does telnet server prevent user session? The sshd can surely do that same.

Do look at ls -l /
You should note that /bin and /sbin are not “real”. They are mere symlinks, aren’t they?

There are many ways to create a shell session: console login, DE GUI login, sudo, sshd, telnet server, cron, etc. Each of them could initialize the environment differently. Some of them might depend on common routines, but telnet server is not likely to be one of them. More-over, the root account has exceptions.

7

With ssh you can lock down things very very much better than telnet-server, especially if you use ssh keys or certificates; I wrote some blog posts introducing the idea of restrictions on the key/cert; check out SSH key management · Ramblings of a Unix Geek and Using SSH certificates - revisited · Ramblings of a Unix Geek

8

With out getting into too much detail about how our application software and database works, we effectively are using telnet to get to the database as a virtual server.

The application takes over and the user does not have access to the Linux command line without permissions inside of our software. However, they can still use the application itself with their application specific usernames and passwords that have nothing to do with Linux. They can also use some Linux functions (such as formatting media) by using our software which prompts the user, creates the needed Linux command, and runs it as root - effectively acting as a front end for the command line for “allowed” actions.

If they use SSH, they go straight to the Linux command line, not our application, and if left to their own devices, always cause trouble. There may be some method of “automating” the SSH login the same way we do with telnet to go straight to our application, but I’m unaware of it.

I should have access to the machine in question again on Monday, so I’ll check out ls -l /

9

Ssh user@remote_host <cmd_on_remote_host> will execute what you want there and exit (close tty) right after unless you want to preserve the tty (-t) for more user interaction.

For extensive interaction you can overlay ‘expect’ the ancient modem robo chat like kermit but they scrape local chat scripts but would need user/pswd on local_host to do sessions

10

See man sshd_config
It appears that you could add:

Match User !ZackGrill
ForceCommand /somewhere/yourDBapplication

and then ‘ssh server’ would run ‘yourDBapplication’ (and only it) on the server, except for account ‘ZackGrill’, who gets shell (or anything else you request).

The users (other than ‘ZackGrill’) could not override that with ssh server bash.
Not sure whether command=bash in authorized_keys can override ForceCommand, but since ‘yourDBapplication’ will not(?) modify that file, that should not be an issue.

[EDIT] Rather that running yourDBapplication directly, you could run a script that sets PATH and then executes yourDBapplication. Then the yourDBapplication would have environment where it finds the necessary utilities.

11

You may have no EXT3 option here.

yum install e2fsprogs

Then try.

12

Unlikely.

Overall, we can ask, which package has a file:

dnf provides *bin/mkfs.ext3

We can also list files of package:

dnf rq -l e2fsprogs | grep mkfs

And ask whether it belongs to any “group”:

dnf rq --groupmember e2fsprogs

which says: core
Not just in core, but a mandatory member, according to:

dnf group info core

Furthermore, the core is mandatory even in Minimal Install:

dnf group info "Minimal Install"

Hence, the e2fsprogs should be present in normal installs. However, a cloud install image is not restricted to Environment Groups.

Anyway, the “barren” PATH is more likely explanation here.