Due to security recommendations i have changed in /etc/passwd
postgres:x:26:26:PostgreSQL Server:/var/lib/pgsql:/bin/bash
to
postgres:x:26:26:PostgreSQL Server:/var/lib/pgsql:/sbin/nologin
after that i am unable to restart my postgres server
i am getting error:
This account is currently not available
The chsh command changes your shell (or by using sudo the shell for another user. And, since you are not able to login, you must execute this command as another user)
sudo chsh postgres -s /bin/bash
Related
I created bash script on Linux Redhat with vim
My script is working well on an user.
I need to esxute on the same script this command
su - root with password
VGDISPLAY -v |grep "LV Status"
the probem is when I execute my script the part of the normal user is done
and the other part with root not done
my question how can I do to execute this
I need to switch in the same script to root
Best regards
I'd recommend not switching to the root user in the script for specific tasks/commands but assigning SUDO privileges to your user (by which you are running the script), and using sudo command in the script for the tasks/commands that need elevations.
Hint: By sudo command you may run a process on behalf of another user (root probably).
If you are not familiar with sudo command or how to assign SUDO privileges to a user, please see the following link or google it.
https://phoenixnap.com/kb/linux-sudo-command
PS. Providing SUDO privileges to a user is configurable whether to be used for all commands or limited commands. For testing purposes, you may configure the user to be able to run all commands with sudo to gain the privileges, but for production use it is strongly recommended to limit the user to be able to use only necessary commands with sudo and nothing more.
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.
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.
I am trying to create a Linux terminal menu by way of a simple script. Within the script it will have some commands that will submit a job (a shell script for example) as another user without password prompt.
I was able to find the following post and this worked. how to run script as another user without password
However, there was one side affect. It appears the user can run other scripts in that users folder which I don't want.
Any suggestions/help welcome.
For the sake of this. Here is what I have:
Username temp1, which is the user that will be running the menu.
uid=1001(temp1), gid=1001(temp1), groups=1001(temp1)
Username wayne, which is the user that the script must be submitted as to run the job
uid=1000(wayne), gid=1000(wayne),groups=1000(wayne),4(adm),24(cdrom),27(sudo),30(dip)...
Script script1.sh, script2.sh owned by wayne.
-rwxr-xr-x script1.sh
-rwxr-xr-x script2.sh
If I try to go to /home/wayne as temp1 user I get permission denied (expected)
I set the scripts to chmod 700 for wayne. So technically no one can run them other than wayne.
I have edited sudo file and have the following entry:
temp1 ALL(wayne) NOPASSWD: /home/wayne/script1.sh
When I run command su -c "/home/wayne/script1.sh" -s /bin/sh wayne the script runs (as expected)
When I run command su -c "/home/wayne/script2.sh" -s /bin/sh wayne the script runs (not expected).
Any ideas?
The answer is change from su to sudo.
su is primarily for switching users, while sudo is for executing commands as other users. The -u flag lets you specify which user to execute the command as:
sudo -u wayne '/home/wayne/script2.sh'
gives Sorry user is not allowed to execute
Solution: In order to run commands/scripts as another user on linux/unix you need sudo permission and run the following formula:
sudo -H -u <user> bash -c '<some-command>'
For example:
sudo -H -u wayne bash -c 'echo "user:$USER|home:$HOME|action:run_script"; ./home/wayne/script.sh'
from Documentation:
sudo allows a permitted user to execute a command as the superuser or
another user, as specified by the security policy.
-H The -H (HOME) option requests that the security policy set
the HOME environment variable to the home directory of the
target user (root by default) as specified by the password
database. Depending on the policy, this may be the default
behavior.
-u user The -u (user) option causes sudo to run the specified
command as a user other than root. To specify a uid
instead of a user name, use #uid. When running commands as
a uid, many shells require that the '#' be escaped with a
backslash ('\'). Security policies may restrict uids to
those listed in the password database. The sudoers policy
allows uids that are not in the password database as long
as the targetpw option is not set. Other security policies
may not support this.
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.