0

I have an application manager that needs to call setfacl to (dis-)allow execution of a certain file by certain users.

This application runs as a non-root user admin (and for a plethora of reasons, I'd like to keep it that way). Therefore the setfacl calls from within manager fail with setfacl: <filename>: Operation not permitted.

My understanding is, that I could give the admin user the CAP_FOWNER capability to allow it using setfacl on files owned by root. I tried doing so, by adding cap_fowner admin to /etc/security/capability.conf. After re-logging in admin, the cap is set:

$ capsh --print
Current: = cap_fowner+i
...

setfacl still fails though:

$ setfacl -b <filename>
setfacl: <filename>: Operation not permitted

The file currently has the following acl:

$ getfacl <filename>
# file: <filename>
# owner: root
# group: root
user::rwx
user:cluster-user2:r--
group::r-x
mask::r-x
other::r-x

I also tried sudo setcap cap_fowner=ie manager (following this) but that does not seem to enable manager to use setfacl internally either.

I'm happy about any clues how to enable using setfacl as a non-root user on root-owned files.

Eventually, I want to run the manager as a systemd service using the user admin. Is there a systemd way to add the required capability?

3
  • Is this a local file or is it served via NFS/SMB/etc? Commented Jan 5, 2023 at 15:32
  • It's in /usr/bin, installed by a deb package. Which is why I'm hesitant to just change the file's owner.
    – fodinabor
    Commented Jan 5, 2023 at 15:35
  • Try sudo setcap CAP_FOWNER=+eip /path/to/binary.
    – harrymc
    Commented Jan 5, 2023 at 15:45

1 Answer 1

1

What you were looking for is the "ambient" capability set – a much later addition to Linux, which pam_cap does not yet support.

Current version of pam_cap only manages "inheritable" capabilities, which per original design only become effective if the file being executed (i.e. /usr/bin/setfacl) also has that capability marked as "inheritable" using setcap cap_fowner=ei <path>.

(Not cap_fowner=eip, as marking the capability as "permitted" would grant CAP_FOWNER rights to the program when executed by any user, even if the user hasn't been granted it via PAM.)

For packaged files, use dpkg-statoverride to change their owner permanently. Alternatively, grant the user sudo rights to run the single command setfacl -m * <filename> as root.

2
  • Thanks! All the options seem to solve the issue permanently and don't seem overly invasive. Will evaluate which to deploy in prod.
    – fodinabor
    Commented Jan 5, 2023 at 15:50
  • 1
    Not entirely – setting capabilities on /bin/setfacl is very much like changing the owner of /bin/setfacl, and would also be lost after a package upgrade. Commented Jan 5, 2023 at 15:54

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .