I want to check if I am using elevated user rights, like running su another_user and seeing my original user name / id.
All I found when researching that topic is either hardcode my own username somewhere, or examples for root user only (id=0).
I think zsh has a variable for that: $DEFAULT_USER, but it's not working in bash.
Related
I was logged in via SSH as the user who was currently logged in.
I enter the remote computer using my admin account.
ssh admin_a#ipaddress
Then proceeded with:
su username_b (current login user)
The result left me in bash-prompt (which I don't understand) as the current user logged in ( tested this by using whoami ).
Q1: When I switch over to the user who is logged in, why does it put me into bash-prompt (i.e. ~bash$ ) - why not ~ username_of_current_user$ ?
After I created the bash script and placed it into the current user's directory - the script is called from launch agents, although it doesn't work.
The error logs showed that one of the variable's output is wrong: whoami = root, when it should = current_user_logged_in.
Q2: Why is the script being called from root?
su - invokes a login shell after switching the user. A login shell resets most environment variables, providing a clean base.
su just switches the user, providing a normal shell with an environment nearly the same as with the old user.
The most obvious example of this is that ~ is root's home directory if you use su -, but your own home directory if you use su.
Depending on your system, it may also mean differences in prompt, PATH, or history file.
For more details:
https://unix.stackexchange.com/questions/7013/why-do-we-use-su-and-not-just-su
I'm trying to execute my test daemon by launchd with logon user privilege.
I saved my plist file at /Library/LaunchAgents/myplist and it was executed well with logon user account at Mavericks.
My command was like this.
$launchctl load /Library/LaunchAgents/myplist
But it was executed as root account when I tried it at Yosemite.
As I know, it should be executed as logon user account, but it wasn't at Yosemite. I also moved myplist file to ~/Library/LauchAgents/myplist, but the result was same.
What happend to Launchd at Yosemite and how can I execute launchd with logon user account?
The user can be specified in the daemon's plist with the UserName key. For example: -
<key>UserName</key>
<string>_daemonUser</string>
Where _daemonUser is the name of the user the daemon should run as, assuming that a user with that name exists.
If you want to use the name of the current logged-in user, you'll have to specify that when calling launchctl load. In a bash script, run with sudo, you can do something like this: -
SESSION_USER="$USER"
echo Starting MyDaemon as user $SESSION_USER
su $SESSION_USER -c 'launchctl load /Library/LaunchAgents/myplist.plist'
You may need to consider other users too, if user switching is applicable and they're already logged-in. This is more complicated, but there's a solution here.
I'm new to linux operating system and I've explored today the /etc/passwd file and to my surprise I found that it contains many other user names like proxy,daemon..etc.What are all these users?Can I login using these users?
Here the cat command i performed on /etc/passwd.
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin
proxy:x:13:13:proxy:/bin:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
irc:x:39:39:ircd:/var/run/ircd:/usr/sbin/nologin
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
libuuid:x:100:101::/var/lib/libuuid:
syslog:x:101:104::/home/syslog:/bin/false
messagebus:x:102:106::/var/run/dbus:/bin/false
usbmux:x:103:46:usbmux daemon,,,:/home/usbmux:/bin/false
dnsmasq:x:104:65534:dnsmasq,,,:/var/lib/misc:/bin/false
avahi-autoipd:x:105:113:Avahi autoip daemon,,,:/var/lib/avahi-autoipd:/bin/false
kernoops:x:106:65534:Kernel Oops Tracking Daemon,,,:/:/bin/false
rtkit:x:107:114:RealtimeKit,,,:/proc:/bin/false
saned:x:108:115::/home/saned:/bin/false
whoopsie:x:109:116::/nonexistent:/bin/false
speech-dispatcher:x:110:29:Speech Dispatcher,,,:/var/run/speech-dispatcher:/bin/sh
avahi:x:111:117:Avahi mDNS daemon,,,:/var/run/avahi-daemon:/bin/false
lightdm:x:112:118:Light Display Manager:/var/lib/lightdm:/bin/false
colord:x:113:121:colord colour management
daemon,,,:/var/lib/colord:/bin/false
hplip:x:114:7:HPLIP system user,,,:/var/run/hplip:/bin/false
pulse:x:115:122:PulseAudio daemon,,,:/var/run/pulse:/bin/false
brucewilson:x:1000:1000:brucewilson,,,:/home/brucewilson:/bin/bash
mysql:x:116:125:MySQL Server,,,:/nonexistent:/bin/false
bharghav:x:1001:1001:bharghav,,,:/home/bharghav:/bin/bash
sshd:x:117:65534::/var/run/sshd:/usr/sbin/nologin
statd:x:118:65534::/var/lib/nfs:/bin/false
snmp:x:119:126::/var/lib/snmp:/bin/false
guest-MSvo95:x:120:127:Guest,,,:/tmp/guest-MSvo95:/bin/bash
Can anyone please explain what are these?
Most of those users are required by the OS processes to work. You can't login as one of those users because:
a. They don't have a shell as regular users does. For example, brucewilson has /bin/bash as shell, but pulse (Audio Controller ) has /bin/false.
b. There are not passwords for those users, so when the system asks for a password, no matter what you type you will never get in. You can check who has a password in /etc/shadow.
Actually, you can login as any user listed in /etc/passwd as of your choice.
for example, if you want to login as proxy, type the following command:
sudo -u proxy /bin/bash
It will asks password to authenticate the access, you can give your password only if your user account is added in sudoers list.
You can use the same command to login as any user in the /etc/passwd file.
For example, again if you want to log in as daemon, type the following command:
sudo -u daemon /bin/bash
and so on...
Hope this will help you.
I've been looking for a way to force usermod to modify the password/group/... files despite the user being in use.
What I do get now is this:
!! Failed to execute 'usermod --home '...' --password '...' --shell '/bin/false' 'zabbix' 2>&1':
usermod: user zabbix is currently used by process 518
I know that for being secure I need to restart the service. But this is done within a setup script. I am restarting all services at the end.
Is there any way to say --force? (well, except for modifying all necessary files.)
Thanks
If you can get root rights via sudo and are confident enough to change system files using vi then I would change the files manually.
Only a few things need to be changed in
- /etc/passwd
here you could change UID, GID, Homedirectory, Shell ...
- /etc/group
here you might need to change UID/GID as well for the username if there was a change
The File /etc/shadow will be changed automatically when using passwd to set a new password. This you can directly perform if you are root: "passwd username"
You can run usermod in a separate user namespace (with a recent enough linux), but you need to map the root user to root (otherwise you won't have permissions to modify /etc/passwd).
I.e. something like this:
unshare --user --map-root-user usermod ...
Now usermod won't find the processes running with the uid of user you are modifying.
You probably won't be able to modify the root user itself with this.
I'm trying to write a bash script that sets up my web development environment in ubuntu. As part of the process of setting up the script, it needs to edit files that are owned by root. It also needs to create fields in the public_html directory of the user that runs the script.
Should I therefore require that the script be run as the superuser? If it should, then how do I get it to access the current user's username? I would normally use the $USER variable, but I can't do that if the script is being run as the superuser. If I'm not the superuser, how can I get the script to request super user privileges for certain operations, while not requiring the user to type in a password for every operation that requires super user privileges.
Thanks
You can use the -E flag for sudo to preserve the environment variables, or, you can set up sudoers to preserve the environment on a per-command basis.
You can also set up the sudoers file to not ask for a password on a per-command basis, for example, to allow user xy to use smbmount without asking for a password:
xy ALL=NOPASSWD: /usr/bin/smbmount
In your case, it would be enough to just store the current user in a variable before invoking sudo, and use the already saved username:
CURRENT_USER=$USER
sudo yourscript.sh $CURRENT_USER
Then read the username from $1.
You can also use the SUDO_USER env variable, which is set to the user who is invoking sudo.
Insert a check at the top of the script:
# Make sure only root can run this script
if [[ $EUID -ne 0 ]]; then
echo "This script must be run as root" 1>&2
exit 1
fi
In this way when you run it without the root privileges you will be prompted, then you can simply rerun it the right way with:
sudo yourscript.sh
More infos at http://www.cyberciti.biz/tips/shell-root-user-check-script.html
There's a command named sudo for this purpose. It lets you specify that certain users can run certain commands as root (or another user).
If your users have root access anyway, you could just write a script that must be run as root and takes an username as parameter, instead of picking up the username.
Alternatively, one way of picking up the login username in an interactive shell is:
stat -Lc %U /proc/self/fd/0
This retrieves the ovner of the tty associated with stdin.
Just make it a setuid file. Or use sudo which is probably safer, since you can limit who gets to run it.
chmod 4755 script.sh
In Ubuntu, there's the SUDO_USER environment variable.
So, you can just run your script sudo somescript.sh and have it pull the invoking user's username $SUDO_USER.
Not sure on other dists, though.