Running a script as another user while knowing who ran the script - bash

In Linux, need to write a shell script which can be ran as other users (via doas permissions for this one script), but I need to know in the script who ran it originally. How would I go about doing this?

From the man page
By default, a new environment is created. The variables HOME, LOGNAME, PATH, SHELL, and USER and the umask(2) are set to values appropriate for the target user. DOAS_USER is set to the name of the user executing doas.
So use $DOAS_USER to get the original username.

Related

Having aliases active in a terminal session without using bashrc or bash_profile or bash_aliases?

This question is an offshoot of my question on whether there's anything wrong with having aliases on a production server.
So I tried creating a shell script with some aliases
#!/bin/sh
echo "creating aliases..."
alias f='clear;cd ..;ls;pwd'
alias ff='clear;cd ../..;ls;pwd'
Did a chmod +x al.sh, and ran the script ./al.sh, but although the "creating aliases..." statement got printed, none of the aliases worked, because they were obviously active only until the script ran.
So is there a way I can run a script containing the aliases I want, which will remain active as long as the terminal session is active? The basic idea being, not to cause problems for colleagues who use the same server.
For cases when you want to store functions and aliases just for your session, I find it quite useful to have a file with them and sourcing it when I login the server.
So just place it somewhere like:
~/nav_alias_file.sh
And then just after sshing the server type:
source ~/nav_alias_file.sh
Note by the way that, as Sundeep expressed in comments, you do not need the shebang in that file.

prevent bash from running user defined binary

In our cluster with PBS batch system (torque) installed, we want all the users to execute their jobs by qsub so that the CPU resources can be well managed. However, we found that users in our cluster can still run their programs directly in their bash shell.
I have noticed that some other cluster systems have restricted users from running their own binary. Their command prompt is different from full privileged command prompt.(starting from ~>)
qczhan2#barrine1:~>echo $0
-bash
In their configuration, users can run basic commands, like ls, pwd, cp, and 'cd' to system folders, but when users run their own binary, the system states "permission not allowed." It is also necessary to mention that if one tries to call user-owned binary using any mpi command, it is also not allowed either.
For example:
qczhan2#barrine1:~>mpiexec -n 64 ./abc.out
permission denied
where abc.out is a user-defined binary file.
I am just wondering how to configure the system to be like that?
You want to change the default shell for all your users from /bin/bash to:
/bin/bash -r
so their shell becomes a restricted shell. Amonst other restriction the users are not allowed to cd, set or unset PATH or issue commands containing /. This locks them into only running commands you give them access to.
If you use Linux: mount filesystems where users have write permission (e.g. /home, /tmp, /var/tmp, /dev/shm) with option "noexec".

Changing login path without modifying $HOME

When I start a terminal session and my shell starts I'd like it to log me in a specific directory instead of $HOME.
For example, I've noticed I often start a new shell session and move to /tmp just to clone a git repository or do some quick and temporary stuff, and I would like to be logged directly in a directory of mine like /sandbox or something at my shell startup rather than my $HOME directory.
Any of you aware of a way to achieve this without modifying my user's home directory nor adding a dumb cd /sandbox in my .zshrc ?
Thank you very much!
My preferred solution for issues like this is to use a bunch of wrapper scripts that set the desired environment properties and then exec an interactive shell, passing through any command line arguments:
#!/bin/sh
# sandbox-sh
cd /sandbox
exec bash "$#"
Even better, you can launch GNU screen or tmux instead of a single shell - any new windows you create will share the same properties as the first one. Alternatively, you may also launch a tabbed terminal emulator - any new tabs will also share the environment defined in the wrapper script.

Shell script to use my login environment

I have crontab running a shell script periodically. I need the script to run in the same environment that I usually log in. Can I just simply add this line in 2nd line of the script (after shebang).
source /home/<my username>/.cshrc
Or what's the proper way to set the cron shell process to use my login environment?
PS: I am quite sure which exactly setting is needed by my script, so I can only source the whole .cshrc.
Try something like that:
sudo su - <user> -c <cmd>
Of course you have to alter the sudoers file first.
Take a look at the man page.
hth

SSH to debian server instantly logs out

I'm trying to help someone with their Debian server.
They have Plesk. I made myself an user with Plesk and enabled SSH access.
I can log on ... but only for one second. I see the MOTD, I see a Debian disclaimer, then I'm logged out again. "Connection closed".
The only thing I could think to try is to change the shell settings, Plesk has a dropdown list of bash, csh, tcsh and so on next to the "allow ssh using:" option. But none of them works.
Any ideas gratefully received.
The way I fixed this problem is, unfortunately, to manually change the last parameter in /etc/passwd for users I want to give shell access. It is /bin/bash instead of /bin/false.
Plesk can get a bit quirky sometimes...
That behavior is similar to the one you get when a user account has a 'nologin' shell selected on the Plesk config. I would do some things:
Connect using ssh with the verbose option activated (ssh -v user#host) so you can get more detail.
Check the /etc/passwd file, look for your user and check that, the final field on that line, is pointing to a valid shell (something like /bin/bash instead of /bin/nologin or /bin/false).
Check also in that line that the home directory for that user ( that's configured on the field before of the shell ), is valid, exists, and has proper permissions and owner
Finally, check your logs (in /var/log; I think I would check syslog, messages and user), so maybe you can get any meaningful message.
When a user logs on, the shell takes them to their user directory and possibly runs a "startup" script.
Is the user directory on the local machine? Does it have to be mounted from a fileshare (this has happened to me on more than one occasion)? If that fileshare is not mounted you will get disconnected.
Take a look at the startup scripts for those shells. Bash uses various startup scripts depending on the circumstance, these include /etc/profile and ~/.bashrc. These scripts sometimes do wacky things that may disconnect you for any number of reasons.

Resources