I have a stupid problem but it is giving me a headache, and I would be very grateful to anyone who wants to give me explanations.
I created a simple script that runs in the background every day by systemd (timer).
This script should run some commands as root and some only as user, but obviously a systemd timer (/etc/systemd/system) runs 100% as root, so those commands that don't want sudo give error.
Is there a way to say: "Run as root only the commands in this script that require it, otherwise run them as a normal user!"?
My OS is Arch Linux, and I use Bash.
In the hope of being made understood well enough (forgive me in case I was unclear), I thank everyone in advance.
I suggest that you read the documentation at https://linux.die.net/man/8/sudo for the sudo command and see if that helps you. If not, perhaps you can ask questions about what you do not completely understand at that page, which documents the command reasonably well.
I hope this helps; if not, reply with questions about this Web page document.
which I see also reported in the man of sudo.
But I can't reach my goal...
Maybe I should think of an alternative solution, maybe moving the timer to /home/$USER/.config/systemd/user, the problem is that by doing so the script would ask for a password in the background and get stuck in an endless loop due to lack of user input.
I think the main issue is not the use of sudo, it is probably the technique you want to use in order to utilize the "timer". A cron entry is probably what you want. You can also experiment with the at command (at a certain time, run a command). The cron entries can run at a certain time, certain days, every day, etc. I recommend evaluating these two techniques and decide if you want to create a regular cron entry, or control the activity in a script with the at command.
Before switching to systemd.timer I used cron for a very short time to run these commands periodically, but honestly I never checked if the commands that do not want sudo were launched correctly with it.
Could Cronie give me this problem too?
The fact is that I have this script with several commands inside, some are preceded by sudo (exactly as if I entered them by hand in the terminal) and I would like them to be launched in the background by the system (so it will not be possible by the user enter the password).
By creating the timer with systemd, then placing it in /etc/systemd/system, I saw that commands that require root work properly and the script runs quietly in background without prompting for a password. The problem is that it skips all commands that want to be run by a normal user (makepkg, for example).
So, I would like to avoid changing visudo, as I would not want to suppress the password prompt for the normal user.
Opting for the method with sudo -u username works, but only until it happens again on a subsequent command that requires sudo, thus asking for the root password. How can I avoid this "exit-entry" from root?
My visudo configuration is set up in such a way that if the user types sudo in order to run a command with root rights, he is prompted for the root password, not his own; consequently, if he does not know it, he cannot issue commands as root.
In any case I would like to be able to set everything so that no password is required by the script in background, neither to execute commands as root, nor for those of the user in question.
This is a small piece of the script in question:
As this is hard to believe, do you mind typing sudo -l using that very specific user account then show us the content of the shudders file for that user?
What I don't understand also is why use sudo when you are root??? as root can su any user without problem and without need of password
How do you think I run production batches when I dont want users to modify my schedule in cron?
Hello vbe,
Why should it be hard to believe?
Just edit two lines in visudo to change its behavior (but I guess you know...).
In any case, if I run sudo -l a very strange thing happens: it does not accept my user's password (and not even the root one, trying)...
To answer the other question:
The presence of sudo in the script is justified by the fact that the script in question is not born immediately as a timer in /etc/systemd/system, but is activated as a timer only later and at the request of the user. Consequently I had to enter sudo to make the script work even if simply launched manually from the terminal by the user.
I have set up my system in such a way that to perform more "important" operations I am prompted for the root password, which is very complex. While the password of my user is very simple, in doing so if I had to leave the computer on and my user logged in, a possible attacker passing through would have a pretty hard life...
Maybe it's the wrong approach, but I've always set up my system this way and I've always enjoyed it.
So, the first sudo is needed in case the user runs this script from the terminal by hand, is asked for the root password and the pacman -Syu etc. etc. command is launched.
The sudo -u username instead I inserted them to test if by chance this would work if the script was set as a timer running daily in the background (with root).
What I'm looking for is a solution that tells the timer (which is run by root) not to run makepkg (in the case of the example in these lines) as root. Is there any way? I cannot break the script into two different scripts where one would contain only root commands and the other only standard user commands, as there are cases in the script where they "intertwine" in an if, or loop, to example...
Thanks a lot MadeInGermany!! Today I will try all your solutions!
I was reflecting on the objections raised by @bendingrodriguez : what would be the "default" solution adopted by Linux users to prevent a normal user from issuing commands as root simply knowing their password? Would it be enough to remove such users from the list of those who can launch sudo?
If so, could such a change to my system make it easier for me to achieve the purpose of this thread? What should I do in that case, give my user the same password as root? Could you give me your point of view, please?
sudo is meant to run a single command or script with a different user, without knowing the latter user's password. The typical example is for your user to run commands as root, but only requiring your own password, if any.
Also, it is fairly granular. The sudoers file (not "visudo" - this is a vi wrapper for sudoers editing) can grant specific users the right to run specific commands. You can even set up groups of users or commands to ease multiple repeated sudo settings.
Go for your best friend - man 5 sudoers - for details.
For you to require root password to run something as root, just do not include it in sudoers nor use sudo to run. Use su -c <Command> <User>, and it will require such user's password (unless you're root).
Again, your best friend will be man 1 su. Plenty of funny options.
I agree. I think that your best option is 1. Read both sudo and su documentation.
2. Follow the suggestions just provided. Su appears to be your best solution.
Only yesterday evening and today I managed to find the time to try to solve my problem. Unfortunately, however, I have not been able to find a solution, neither within the man page of sudo and of su, nor by trying your suggestions.
I try to go into detail, so maybe we can find a solution together.
Here is a piece of the script in question:
If I go to insert it in /etc/systemd/system and activate the related service, it works until it arrives to the -i of makepkg -sirc: at this point it asks the user for sudo password since there is the -i option.
If instead I go to insert it in /home/$USER/.config/systemd/user, it rightly asks for the root password.
Finally, I remember that this script is designed both to be launched "by hand" by the user when needed (hence the need to insert the first sudo, for example), and to be able to be launched automatically by the system in the background without requiring any input from the user.
Thank you again to all, guys!
simply knowing their passwordis the purpose of sudo. This is for the sake of security, as s/he cannot disclose any other pwds, intentional or not - cause s/he simply doesn't know them. If the user knows root's pwd, sudo isn't needed, but su.
A user doesn't belong to the sudo group by default, root has to add her/him explicitly to the group, e.g. via
usermod -a -G sudo user
To 'enable' it for the user, s/he has to logoff and login again.
If the user doesn't belong to the group, s/he isnt' allowed to call sudo:
foo@host$ sudo -i -u bar ls /root
foo is not in the sudoers file. This incident will be reported.
To allow root to call commands as an arbitrary user via sudo without a pwd, you have to put an entry like
root ALL=NOPASSWD: /usr/bin/foo,/bin/bar
in the sudoers file. However, it doesn't make much sense to have root ask about pwds. root is root is root. So that entry should rather be
