I use centos v6.5 as os and i realize that value of $USER variable is not changed when i su with other user.
Is it a bug or my misunderstanding of su concept?
Related
There are commands that require users to be in a group to execute.
I am running a non-interactive bash script script.sh like below
#!/bin/bash
sudo usermod -aG $USER docker
# this line requires user logging to succeed
docker ps
When invoking the script for the first time bash script.sh, the line docker ps will complain insufficient permission since the new group membership modified by line sudo usermod -aG $USER docker requires the user to re-log into the shell to take effect.
My question: is there a way I can trigger the re-log in an non-interactive way?
When you make changes to users like adding, removing groups, you will have to logout from the current session and then, you will be able to use the docker command without any problem.
Another solution if you are working with terminal can use the su command.
For example, your script can be like this:
#!/bin/bash
sudo usermod -aG $USER docker
su - $USER #this line is used to login with the $USER as a login shell
The docker ps command will not work in this script, I forgot to mention that when you run su - $USER you will have to type that command inside that login shell.
But, there is another solution for that, you can use the -c option for su command. For example:
su - $USER -c "docker ps"
Or if you want to use several command you can try using a semicolon at the end of each script:
su - $USER -c "docker ps;docker images;..."
Or if you will have several commands, you can save them inside a file and send the text as parameter of the -c option:
In your text file might be (dockerscripts.txt):
docker ps
docker images
docker info
And the su command might be:
su - $USER -c "$(cat dockerscripts.txt)"
A tip for checking the current groups of a logged user is to use the command groups
So, if you try this:
sudo usermod -aG $USER docker
groups # this will display the current groups of $USER but the `docker` group will not be there yet
su - $USER
After that command you will be in the login shell, so you will have to type the command groups and when you run it, this will display the current groups of $USER including the docker group.
Note: When you logout from the login shell su - $USER the group will not be there again, so If you want to use the docker command you will have to use su - $USER again. The effective way for working with the new group is to log out from the session (if you are working with a desktop environment).
You can check this link fore more useful information: newgrp command in Linux
I'm a new user of Linux. I installed ZSH and made it my default Shell according to the guide on its GitHub but I used Sudo by mistake. Is it OK? or do I need to undo what I've done and just change it with user permission?
You probably just made it the default shell for root. It won't cause you any issues if that is what you did.
# set default shell for a non-root user:
$ sudo --user <USER> chsh -s /bin/zsh
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 am using Bash on Lubuntu 16.04. LTS, but I'm not sure if this matters much for this question.
I noticed, that when I create a file as standard user, the file has 664 permissions. But when I am root and execute the same command for the same user via the -u argument, it has 644 permissions, so the write permissions for the group are missing.
I suppose this to be a flaw, since the sudo manpages clearly state:
-u user, --user=user
Run the command as a user other than the default target user (usually root). The user may be either a user name or a
numeric user ID (UID) prefixed with the ‘#’ character (e.g. #0 for UID 0). When running commands as a UID, many
shells require that the ‘#’ be escaped with a backslash (‘\’). Some 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.
Now that I know that the -u argument's behavior differs from the behavior that has to be expected, my question is:
How can I make sure, that a command that is started in a root shell gets executed exactly as it would be executed from another user's shell?
Remark: I know that I could fix this one problem by tinkering with the umask, but this won't guarantee me that the behavior doesn't differ in an arbitrary amount of other cases.
It looks like the umask depends on whether the shell is interactive:
$ umask
0002
$ sudo -u $USER bash -c umask
0022
$ sudo -u $USER bash -ic umask
0002
This appears to be from from /etc/bashrc, which applies umask 002 only if
it's not a login shell,
the UID is greater than or equal to 200, and
the username is equal to the group name,
or from /etc/profile, which applies umask 002 if the last two criteria are met. I'm not sure if something else is overriding this, because shopt login_shell prints the same whether the shell is interactive or not, and the UID is also the same.
You can get the user's default shell thusly:
$ getent passwd $USER | cut --delimiter=: --fields=7
/bin/bash
Combining them:
$ sudo -u $USER $(getent passwd $USER | cut --delimiter=: --fields=7) -ic umask
0002
A nice and clean solution that shows the expected behavior is this:
sudo su <username> -c '<any commands>'
I have a problem with my situation that i have to run a script inside another machine as root. I can only do ssh without password as oracle, so i have to write something like that:
su - oracle -c "ssh $node /tmp/x.sh"
How can i run x.sh as root?
EDIT
[root#alz1 ~]# su - oracle
[oracle#alz1 ~]$ su
Password:
su: incorrect password
[oracle#alz1 ~]$
Have you tried
su - oracle -c "ssh root#$node /tmp/x.sh"
Try this:
[root#box1]# su - oracle
[oracle#box1]$ ssh box2
[oracle#box2]$ su -
Then type the password for root at the remote box. It should then proceed as
[root#box2]# /tmp/x.sh
and you're done.