Not sure where to ask. It is a general Linux question, maybe with a small relation to YaST.
I would like to have a few shell scripts to facilitate administrative tasks. Should be executable from standard Konsole with sudo xyz. I figure such scripts should be stored in /usr/local/sbin. However, that directory is not in the sudoers path. I know I could edit /etc/sudoers and prepend the two /usr/local/sbin and /usr/local/bin to the secure path defined therein.
But I am reluctant since that is not the openSUSE / Tumbleweed default.
My questions:
Is it good practice to do that? Safe? (I am the only user.)
If so, is /etc/sudoers the correct file to edit (visudo)? Or any other?
Who would overwrite such construct? zypper dup? YaST > sudoers?
Any other good location to store my scripts in accord with Linux conventions?
I have a few executables that root uses for adminitrative purposes. I have stored them in the bin directory of the home directory of root (/root/bin). That is in root’s PATH (not changing anything from the defaults).
It is also independent from any sudo use (I never use sudo).
I am not sure why a thing like /usr/local/sbin exists. AFAIK /sbin exists so that even when you have /bin as a separate file system (nowadays almost never done, but that was not unusual 30 - 40 years ago) /sbin would always be there (as part of the / file system). Even if for some reason mounting went wrong. This to have crucial administrative tools always avaliable. I fail to see how /usr/local/sbin can fullfill the same strategy.
Needless to say that /root/bin is always part og the / file system, else root would even be unable to login on a system with the / file system only.
My takeaway 1 would be: No strong objections against modding /etc/sudoers, IF AND ONLY IF one sticks to using sudo.
Takeaway 2: Maybe one should follow your strategy and avoid sudo whenever possible. So, how do you do things like zypper ref/dup on TW then? Log in on TTY as root? And use root Konsole (under KDE the ”red“ terminal icon) to do admin tasks when it is not recommended to have no GUI DE?
Hi
Open a terminal, run screen, switch to root user and zypper -vvv dup (I avoid sudo like the plague well except for /usr/bin/build). Then see what’s running afterwards with zypper ps -s and decide if need a reboot or logout/login. With kernel updates since I use the nvidia blob, boot to multi-user target, rebuild the driver and reboot…
IMO…
Configuring an account with permissions to execute very specific commands only which require elevated permissions is a good approach to granting very narrow rights (only what is sufficient and not for example all of /usr/bin and /usr/sbin) to do the task and then sudo-ing to that account. So, for example if you intend to use the account only to upgrade the system, then that account would be given permission to do only that task and no more.
This has advantages over simply “su” or even a relatively unbounded “sudo” which by default grants broad elevated permissions, and could be a preferred method on a “Text only” system which does not have the option to run a windowed console. Although “screen” allows multiplexing the logged in terminal, I wonder how secure that really is, at least superficially a screen terminal appears to be equally exposed as the main, logged in terminal which is not necessarily the case in an X window console.
Like all other security related issues, what I’m describing here would mainly be for the “more paranoid than usual” – I’m sure that most Users who are less paranoid about what can happen considering the relative difficulty of hacking a terminal (for most people if you set up everything else correctly) can simply su or sudo with default security with little worry of being hacked.
Although one can probably modify the sudoers file, my approach to similar ends probably would instead be to simply give the special account ownership of the needed executables, or create a special User Group with permissions to execute those specific commands (as opposed to carte blanc access member of the wheel group).
Ultimately, it is your decision how best to handle things administratively.
Personal choice: I’ve been a “csh” user for 30 years. So I want to use “csh” with root.
I create a directory “/croot” for that, and I add a few scripts to “/croot/bin”.
I rarely use “sudo”. I prefer to use “su” or “ssh” to get to the root account.
I then run:
HOME=/croot exec csh
That makes “csh” my shell for this root session. Best to use the same shell as root, because that way I am less likely to make dumb mistakes.
There is a shell startup file in “/croot” which adjusts my path to include “/croot/bin”.
I do symlink so that “/croot/.ssh” also shows up as “/root/.ssh”. That way, ssh into the root account with public key authentication works using what I have setup in “/croot/.ssh”.
Note that I use the root account as little as possible. I use my ordinary user account for anything that does not require root privileges.
I am not suggesting that you do the same. But it can sometimes be useful to know what other people do.
I would only put specific comands and not directories in the /etc/sudoers file. Further - for scripts I would use the NOPASSWD option that I don’t have to write the password in a script. For example as one user I have a script to mount and unmount the NAS, therefore I have the line “<username> <computername>=NOPASSWD:/bin/mount,/bin/umount” in the /etc/sudoers file. Then the script which is in the bin folder in my home directory can be executed with the “sudo mount …” command with out a password.
Just would like to say THANKS during the ride for all your contributions. Marvelous that a tiny question triggers a good amount of years of expertise being shared here. I will definitely think about the various ways of good practice. Lots of things to learn!
Please, keep on whoever would like to add. I‘ll keep returning here, just a thank you for now.
well except for /usr/bin/build). Then see what’s running afterwards with zypper ps -s and decide if need a reboot or logout/login. With kernel updates since I use the nvidia blob, boot to multi-user target, rebuild the driver and reboot…