-
Notifications
You must be signed in to change notification settings - Fork 31
Description
Pelican Version:
sh-5.1# osdf --version
Version: 7.14.1
Build Date: 2025-03-07T23:00:31Z
Build Commit: 9cfca469cc43a8d9294fdc397b4a2ffb14bcc966
Built By: goreleaser
Pelican Service:
- Client
- Plugin
- Registry
- Director
- Origin
- Cache
- Other (please give the detail)
Describe the bug
When setting
Server:
DropPrivileges: true
UnprivilegedUser: pelican
to enable priveledge dropping from a root user to the pelican user, the origin fails to start. Upon investigation, it seems that xrootd is failing to start up due to permissions issues while trying to access /run/pelican/xrootd/origin/xrootd.cfg. For the default value of Origin.GlobusConfigLocation: /run/pelican/xrootd/origin/globus, Pelican will try to chown /run/pelican/xrootd/origin/globus to the unpriveledged user, and if the parent directories for that path don't exist, to create them with the same owner and permissions (i.e. pelican:pelican 640) code link. This causes the whole /run/pelican and /run/pelican/xrootd directories to dis-allow the xrootd user from accessing anything within.
Expected /run/pelican/xrootd/origin/xrootd.cfg perms:
namei -l /run/pelican/xrootd/origin/xrootd.cfg
f: /run/pelican/xrootd/origin/xrootd.cfg
drwxr-xr-x root root /
drwxrwxr-x root root run
drwxr-xr-x xrootd xrootd pelican
drwxr-xr-x xrootd xrootd xrootd
drwxr-xr-x xrootd xrootd origin
-rw-r----- root xrootd xrootd.cfg
Actual /run/pelican/xrootd/origin/xrootd.cfg perms with bug:
namei -l /run/pelican/xrootd/origin/xrootd.cfg
f: /run/pelican/xrootd/origin/xrootd.cfg
drwxr-xr-x root root /
drwxrwxr-x root root run
drwxr-x--- pelican pelican pelican
drwxr-x--- pelican pelican xrootd
drwxr-x--- xrootd pelican origin
-rw-r----- root xrootd xrootd.cfg
Setting Origin.GlobusConfigLocation: /globus-test-dir allowed the origin to serve normally, with expected /run/pelican permissions, and created a globus-test-dir sub-directory in the / dir with drwxr-x--- pelican pelican permissions and ownership.
It is likely that other components / config defaults may be affected as well if they try to chown files or directories that don't exist to the unprivileged user, and attempt to create parent dirs owned to this user if those parent directories need to be accessible by other users (xrootd, other users on multi-user origins where xrootd switches to other users to access files, ect.)
Expected behavior
The components should serve properly as the unprivileged user.