群权限被拒绝 bash

Question

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

Answer 1

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.

Answer 2

通过sudo /path/script.sh而不是仅使用/path/script.sh运行整个脚本

Answer 3

This changed I found in Ubuntu 20.04 from 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