flock permission denied bash - bash

I have written a little test script to prevent running my script simultaneously with flock:
#!/bin/bash
scriptname=$(basename $0)
lock="/var/run/${scriptname}"
umask 0002
exec 200>$lock
flock -n 200 || exit 1
## The code:
sleep 60
echo "Hello world"
When I run the script with my user and try to run the script with another user I got following error message with the lock file.
/var/run/test.lock: Permission denied
Any idea?
Kind regards,
Andreas

In a comment, you mention that
other user is in the same group. file permissions are -rw-r--r--
In other words, only the first user has write permissions on the lock file.
However, your script does:
exec 200>$lock
which attempts to open the lockfile for writing. Hence the "permission denied" error.
Opening the file for writing has the advantage that it won't fail if the file doesn't exist, but it also means that you can't easily predict who the owner of the file will be if your script is being run simultaneously by more than one user. [1]
In most linux distributions, the umask will be set to 0022, which causes newly-created files to have permissions rw-r--r--, which means that only the user which creates the file will have write permissions. That's sane security policy but it complicates using a lockfile shared between two or more users. If the users are in the same group, you could adjust your umask so that new files are created with group write permissions, remembering to set it back afterwards. For example (untested):
OLD_UMASK=$(umask)
umask 002
exec 200>"$lock"
umask $OLD_UMASK
Alternatively, you could apply the lock with only read permissions [2], taking care to ensure that the file is created first:
touch "$lock" 2>/dev/null # Don't care if it fails.
exec 200<"$lock" # Note: < instead of >
Notes:
[1]: Another issue with exec 200>file is that it will truncate the file if it does exist, so it is only appropriate for empty files. In general, you should use >> unless you know for certain that the file contains no useful information.
[2]: flock doesn't care what mode the file is open in. See man 1 flock for more information.

I was trying to use flock on a file with shared group permissions with a system account. Access permissions changed in Ubuntu 19.10 due to an updated kernel. You must be logged in as the user who owns the file, and not a user whose group matches the file permissions. Even sudo -u will show 'permission denied' or 'This account is currently not available'. It affects fifo files like the ones used by the flock command.
The reason for the change is due to security vulnerabilities.
There is a workaround to get the older behaviour back in:
create /etc/sysctl.d/protect-links.conf with the contents:
fs.protected_regular = 0
Then restart procps:
sudo systemctl restart procps.service

Run the whole script by sudo /path/script.sh instead of only /path/script.sh

Related

How can I run a command in a separate terminal using sudo without further user interaction

I am trying to automate the running of several tasks, but I need to run them as sudo.
I want to run them in separate terminals so I can watch the output of each.
Here is a sort of minimal example I have setup (because what I am trying to do is more complicated)
Setup two files - note that data is readable as root only and contains 3 lines of example text:
-rw------- 1 root root 33 Nov 15 09:29 data
-rwxrwxrwx 1 root root 11 Nov 15 09:30 test.sh*
test.sh looks like:
#!/bin/bash
cat data
read -p "Press enter to continue"
Also I have user level variable called "SESSION_MANAGER" that is setup in the bash startup... which seems to cause some issues (see later example)
So now I want to spawn various terminals running this script. I tried the following:
Attempt 1
xfce4-terminal -e './test.sh'
output:
cat: data: Permission denied
Press enter to continue
Attempt 2 - using sudo at the start
~/src/sandbox$ sudo xfce4-terminal -e './test.sh'
Failed to connect to session manager: Failed to connect to the session manager: SESSION_MANAGER environment variable not defined
(xfce4-terminal:6755): IBUS-WARNING **: The owner of /home/openbts/.config/ibus/bus is not root!
output:
this is some data
more data
end
Press enter to continue
here you can see that the output of the data file is print ok, but I had some issue with the session manager variable.
Attempt 3 - using sudo in the command
~/src/sandbox$ xfce4-terminal -e 'sudo ./test.sh'
output:
[sudo] password for openbts:
this is some data
more data
end
Press enter to continue
here you can see that everything was well... but I had to enter my password again, which somewhat kills my automation :(
Attempt 4 - start as root
~/src/sandbox$ sudo su
root#openbts:/home/openbts/src/sandbox# xfce4-terminal -e './test.sh'
Failed to connect to session manager: Failed to connect to the session manager: SESSION_MANAGER environment variable not defined
output:
this is some data
more data
end
Press enter to continue
Here, again the output looks good, but I have this SESSION_MANAGER issue... Also the new xfce4-terminal comes out with messed up font/look - I guess this is the root users settings.
Questions
How can I run multiple instances of test.sh each in a new terminal and not have to enter passwords (or interact at all). I can enter the password once at the start of the process (in the original terminal)?
As you can see I got this sort-of working when going in a sudo su, but this issues here are the SESSION_MANAGER variable - not sure if that is an issue, but its very messy looking, but also the xcfe4-terminal looks bad (I guess I can change the root settings to the same as my user settings). So how can I avoid the SESSION_MANAGER issue when running as root?
If you change user-id before you launch your separate terminal, you will see the session-manager issue. So the solution is to run the sudo in the terminal.
You do not want to type passwords in the sudo. You can do that by adding
yourname ALL=(ALL) NOPASSWD: ALL
to /etc/sudoers (at least on slackware). You could also try to set the permissions on the files correct so you would not need root all the time.
Note that adding that line has security implications; you might want to allow just cat without password (in your example), or make even more elaborate rules for sudo. The line I gave is just an example. Personally, I would look at file-permissions.

How to Execute a cmd or sh file in the ssh

I have just got some domain hosting and I am wondering how to execute a CMD or a .sh file.
I am attempting to make a game server but the software requires me to execute the file. The file managers are rubbish and I have a Nexus 7 that can do FTP. I think I missed something just let me know if you need more information.
You must set executable permission to the .sh file in order to execute it in console.
First of all I am not sure if you could execute it with a cli ftp connection to the hosting.
You must connnect via ssh, then cd the directory where the .sh file is, then change the permission.
If you only want to execute the file, and you don't care the code, then give only execute permission to the file for your user with: chmod 100 file.sh then execute it with ./file.sh
If you want to read the code, then chmod 500, and if you want full perms for your user then chmod 700 make any combination to give or deny perms for users in your own group, or for others.

Allowing users to run script via /etc/sudoers and permissions

I'd like users in staff group who do not have admin/root permissions to run the following script without being prompted for a password. This is in OSX.
Note that /usr/sbin/serveradmin requires root/sudo privileges.
I've tried adding the following to my /etc/sudoers, but it does not work. Script has permissions of 755.
%staff ALL=NOPASSWD: /usr/sbin/serveradmin stop smb,/usr/sbin/serveradmin start smb
%staff ALL=NOPASSWD: /bin/sh /opt/scripts/restart-smb
Here's the shell script:
#!/bin/bash
#
# This script simply restarts SMB (Samba)
#
echo "Stopping SMB..."
/usr/sbin/serveradmin stop smb
echo "Pausing for 30 seconds..."
/bin/sleep 30
echo "Starting SMB..."
/usr/sbin/serveradmin start smb
echo "Script complete!"
Your ideas, suggestions most appreciated!
Dan
WARNING while playing with the /etc/sudoers file managing users privilege and permissions, I CRASHED Ubuntu.
Normal login was not possible anymore. I got a parsing error coming from a simple space missing between # and % character in a line I wrongly commented #%sudo ALL=NOPASSWD: /pathtoscripts/script.sh .
I had to recover it with the install/liveCD mounting again the hardrive filesystem, put back the original file in place and dismount the volume for recording changes.
For the above reason I would NOT RECOMMEND THIS METHOD first because it modifies /etc/sudoers privileges critical file. Choose first alternatives available unless:
you have a good back up of your data outside of your PC
you are not afraid to take the risk to repair/reinstall your system
you know the RIGHT SYNTAX of the /etc/sudoers file, trials and parsing errors could cost you a lot of time and/or efforts/crashes...
Reading the other posts, I managed to get it work on my system, managing permissions through a group:
I created the group mygroup
sudo groupadd mygroup
I added the user myuser which will execute the script
sudo usermod -a -G mygroup myuser
I added at the END of /etc/sudoers the entry, otherwise the privilege are overwritten by the previous lines (be careful with syntax)
%mygroup ALL=NOPASSWD: /mypath/to/myscripts/myscript.sh
The above script myscript.sh must have execute permission
sudo ugo+x /mypath/to/myscripts/myscript.sh
This script will then be able to be launched by the user myuser directly as below wihtout prompting for password anymore
sudo /mypath/to/myscripts/myscript.sh
Alternatively, the script can be launched within another one in a same way
I found another way without creating a group, adding to /etc/sudoers file (at the END of file) the line:
%sudo ALL=NOPASSWD: /mypath/to/myscripts/myscript.sh
In case the script must only be launched by a few existing users myuser1, myuser2, it is always possible to only add to /etc/sudoers (at the END of file) the lines :
myuser1 ALL=(ALL) NOPASSWD: /mypath/to/myscripts/myscript.sh
myuser2 ALL=(ALL) NOPASSWD: /mypath/to/myscripts/myscript.sh
I was able to make this work by adding the following to my /etc/sudoers file:
%staff ALL=/opt/scripts/restart-smb
Then of course making the script executable (I had forgotten that).
Still requires a password (which is okay), but working.

In a bash script executed on boot, how do I get the username of the user just logged-in?

I need to execute a bash script on boot.
To do so I created a file
/etc/init.d/blah
I edited it and added the following lines
#! /bin/sh
# /etc/init.d/blah
touch '/var/lock/blah'
username1=$(id -n -u)
username2=$(whoami)
touch '/var/lock/1'${username1}
touch '/var/lock/2'${username2}
exit 0
The script is execute with root privileges (which is what I need because I have to use mount inside this script) .. but the problem is that I also need to know the username of the user who has just logged-in beacuse my goal is to mount a certain folder to a certain mount-point depending on the username, like
mount -o bind /home/USERNAME/mount-point /media/data/home/USERNAME/to-be-mounted
Going back to the boot script, if I do
sudo update-rc.d blah defaults
and then reboot and log-in with my username (let's say john) both ways to get username in my script produce root in fact I've got 3 files
/var/lock/blah
/var/lock/1root
/var/lock/2root
So, how can I get the username of the user who just logged-in? (john in my example)
EDITED:
I solved in this way:
1. I created a .desktop file for each user I need to perform automount on boot to autostart a script on boot (I'm on LXDE) and put it on /home/{username}/.config/autostart
[Desktop Entry]
Type=Application
Exec=bash "/path/to/mount-bind.sh"
2. I stored in that path a bash script called mount-bind.sh and made it executable:
#!/bin/bash
_username=$1
if [[ -z "${_username}" ]]; then
_username="$(id -u -n)"
fi
mkdir -p "/home/${_username}/mount-folder"
sudo mount -o bind "/media/data/home/${_username}/mount-folder" "/home/${_username}/mount-folder"
exit 0
3. I added the following line to /etc/sudoers
%nopwd ALL=(ALL) NOPASSWD: /bin/mount
4. I created the nopwd group and added to it all the users I need
In his way after login I can mount the path under the user home.
Problem with this method is that I have to create the desktop file for each new user and add him/her to nopwd, but it works.
Any further improvement is welcome! :)
I think you should move from a boot time init script to a script executed at login time under the logged-in user. To allow this, you should look into ways to allow your users to execute the mount command you need. Depending on what you are trying to achieve, one of the following methods may help you:
Assuming you are on Linux or some other UNIX with a similar feature, add the mountpoint to /etc/fstab with the user option, allowing normal users to mount the entry.
Execute mount through sudo with a suitably narrow sudoers configuration as to not allow users to execute any mount commands.
Write a suid-root program in c which executes the required mount commands when called. This however is very tricky to get right without creating gaping security holes.
Login does not happen at boot time. You cannot foretell which user is going to log in when booting.
Try Exporting the logindetails and use it.
export username2=$(whoami)

Writing a bash script that performs operations that require root permissions

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.

Resources