My understand is that sudo is executes a given command with root privileges, but I experienced that entering a command in Terminal with sudo caches the authorization. How does it actually works?
For e.g.
sudo fdisk -l
[sudo] password for xxxxx:
(once I authorize by entering a password, successive sudo commands are not prompting for passwords)
sudo fdisk -l
(not prompting for password)
sudo mount -t vfat /dev/sda1 /media/test
Whether sudo is really a wrapper for su (substitute/switch user)?
man sudo would tell:
Security policies may support credential caching to allow the user to
run sudo again for a period of time without requiring authentication.
The sudoers policy caches credentials for 15 minutes, unless overridden
in sudoers(5). By running sudo with the -v option, a user can update
the cached credentials without running a command.
It also says:
-k [command]
When used alone, the -k (kill) option to sudo invalidates
the user's cached credentials. The next time sudo is run a
password will be required. This option does not require a
password and was added to allow a user to revoke sudo
permissions from a .logout file. Not all security policies
support credential caching.
When used in conjunction with a command or an option that
may require a password, the -k option will cause sudo to
ignore the user's cached credentials. As a result, sudo
will prompt for a password (if one is required by the
security policy) and will not update the user's cached
credentials.
Here goes proper detail for you:
Yes sudo and su command is bit different:
1.) When we fire su command it will act as a pure Admin (We can same permanently for that session time)
2.) Whereas, sudo command is acts as a having or assigning admin priviledges (We can say temporary for that session only)
Another Example:
In windows system, hope you have checked right click properties like "Run as Administrator", this is same as sudo.
And if we login or switching user to Admin, it purely acts as a Administrator for all the programs.
Hope you have understood my example, this was best from my side
In your /etc/sudoers you can edit the sudo configuration.
There is a default timeout of authorization.
You can even assign some of your user using sudo without requirement of a password.
Or some user once authorized, it won't require password until you logout your system.
Related
I have a linux user (user2) which has set as shell /usr/sbin/nologin (to block logins). No when I try to switch to this user with sudo su user2 I get the info that this account is not available. But whe I user sudo -su user it works fine.
What is now the difference between su and -su. Or what does -su. I tried to get the help with -h or --help or the manpage but I coulnd not find anything helpfull.
sudo -su user is short for sudo -s -u user. The -s option means to run the shell specified in the environment variable SHELL if this has been set, or else the user's login shell. The -u user option means to run the command as the specified user rather than root. These options are documented under man sudo.
sudo su user will use sudo to run the command su user as the root user. The su command will then invoke the login shell of the specified username. The su user command could be run without the use of sudo, but by running it as root it will not require the password of the target user. For more information see man su.
So the two commands look similar (largely coincidentally) and have a somewhat similar effect when the target user has the same login shell as that of the invoking user. However, in the case that the SHELL environment variable is set in the invoking user's environment (which it usually is, and it is typically /bin/bash), and that the target user has a login shell which differs from this (such as /usr/sbin/nologin), there is then a difference between which shell gets executed by these two commands, and this is what you are seeing.
I think this may be a configuration issue, but I'm looking for confirmation/suggestions.
From terminal or script, the following:
user1$ sudo su - user2 -c "pwd"
prompts me for the original user1's password. However, the following:
user1$ sudo su - user2
user2$ pwd
user2$ /home/user2
works just fine.
sudo - l is showing correct permissions for user1 to switch to user2, and I'm a bit stumped as to why passing a command in via -c argument fails, but performing each step individually works just fine.
Thanks in advance for suggestions.
From man sudoers:
runaspw
If set, sudo will prompt for the password of the user defined by the runas_default option (defaults to root) instead of the password of the invoking user when running a command or editing a file. This flag is off by default.
...
targetpw
If set, sudo will prompt for the password of the user specified by the -u option (defaults to root) instead of the password of the invoking user when running a command or editing a file. Note that this flag precludes the use of a uid not listed in the passwd database as an argument to the -u option. This flag is off by default.
You need to check your /etc/sudoers file. Add to it:
Defaults targetpw
To make sudo ask for the target use password always.
Here is my script:
script.sh:
sudo cat /etc/passwd-
If I am in a sudo session (e.g I ran an other command with sudo a few minutes ago), and now run
script.sh
The script will get sudo access. However if I run cat /etc/passwd-/, I will get a permission denied error.
As a user, I wouldn't expect script.sh to be able to get super user privileges so simply (e.g without me giving access to superuser privileges with sudo script.sh).
Is this expected behavior ?
Is it configurable ?
I see that behavior as being completely similar to sudo su, e,g potentially giving superuser access to any script you run in that session, but even worse, because you might not even be aware of it, and don't know when it ends (at least not without checking manually)
Is this expected behaviour ?
Yes, indeed, it is expected behavior. User's cached credential for sudo is responsible for it.
Is it configurable?
Yes, it is configurable.
And I think your security concern is a valid one. Running script.sh in a terminal where a sudo command is run before (within a certain timeout), will give the script superuser privilege if the script is written with explicit sudo commands.
You can avoid any script not prompting for a password when run as sudo by running it with:
sudo -k script.sh
It will ask for a password regardless of any previous sudo command/s or session.
And to run script.sh without sudo i.e with just script.sh and still prompt
for a password for the sudo command/s:
You can change the timeout value (the duration sudo maintains the session) permanently:
run sudo visudo
Then change the line:
Defaults env_reset
To
Defaults env_reset,timestamp_timeout=0
Save and exit (ctrl+X then Y)
This will ensure that sudo asks for a password every time it is run.
Or If you don't want to change it permanently and want your script to prompt for password at least once (while maintaining a session), then you can change your script like this:
sudo -k first-command-with-sudo
sudo second-command
sudo third
and so on
This script will prompt for password at least once regardless of any previous sudo command/s or session.
In case you are unaware of (or don't have access to) the content of the script script.sh (it can have sudo commands inside it or not)
And you want to be sure that any sudo command will surely prompt for password at least once, then run sudo -K (capital K) before running the script.
Now if you run script.sh and if it contains a sudo command, it will surely prompt for password.
Using 'Execute shell script on remote host using ssh' option and need sudo rights on remote server to change permissions and remove protected files.
How to run session with this rights?
Getting message
sudo: sorry, you must have a tty to run sudo
when trying to run sudo command.
To run sudo remotely you have 2 options
Allow the user to run sudo commands without a password.
Append username ALL=(ALL) NOPASSWD: ALL the /etc/sudoers file with sudo visudo. Alternatively you can modify this line to only allow certain sudo commands to be run without a password
Use the pseudo-tty to emulate tty remotely and enter your sudo password when requsted.
To do this run ssh -t username#host command_to_execute
If the remote server accepts the direct login of the root user you can simply do:
ssh -l root yourserver command_to_execute
Similar syntax is:
ssh root#yourserver command_to_execute
Mind that allowing the login of the root user via ssh to a remote server isn't always a good solution.
A better solution would be change the owner / permissions to allow a non-root user to modify the protected files.
I have a launcher script in Linux Mint 13 so that I can click an icon on the desktop to mount my NAS. In order to use /bin/mount without a password I must add this line to sudoers:
<username> ALL = NOPASSWD: /bin/mount
The script to mount the NAS is very simple:
#!/bin/bash
if [ 0 = `sudo mount |grep -c nasbox` ]
then
sudo mount -a
fi
If I use a terminal my script works without the need to enter a password but when it is run from a launcher (using "Application in Terminal") it asks for the password. If I give the password it accepts it and runs - so it must know which user is running it and allow the user to use sudo, so it does honour part of sudoers, but it doesn't honour the NOPASSWD keyword for /bin/mount. How do I get the NOPASSWD to work here?
Delete /var/run/sudo, /var/lib/sudo, and /var/db/sudo to flush out anything that sudo may have cached. Then make sure that your system's time and date are set correctly. As a (paranoid) security measure, sudo may prompt for the password if it determines that the system clock is unreliable.
This actually happened to me once on a system without a persistent RTC clock. I think I solved it by removing those directories and setting the system clock to a future value at startup. The sudo utility may have changed by now, so I'm not sure if this still applies, but give it a try!