gssproxy

#239 Running gssproxy as a non-privileged user
Closed: Fixed by rharwood. Opened by slev.

Closed: Fixed
Reopen Issue

gssproxy has an option "run_as_user":

run_as_user (string)
        The name of the user gssproxy will drop privileges to.

I've checked it against FreeIPA.
Of course, all required permissions for directories/files have been granted.

There was an error message:

gssproxy[9862]: Unexpected failure in realpath: 13 (Permission denied)

Which came from:

lstat("/proc", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
lstat("/proc/4054", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
lstat("/proc/4054/exe", {st_mode=S_IFLNK|0777, st_size=0, ...}) = 0
readlink("/proc/4054/exe", 0x7ffe7dbf5ee0, 4095) = -1 EACCES (Permission
denied)

This breaks gssproxy:

       program (string)
           If specified, this service will only match when the program being run is the
           specified string.

How to fix.

According to proc(5):

Permission to dereference or read (readlink(2)) this symbolic link is governed
by a ptrace access mode PTRACE_MODE_READ_FSCREDS check; see ptrace(2).

As it was kindly suggested on this thread:
https://lists.fedoraproject.org/archives/list/gss-proxy@lists.fedorahosted.org/thread/BVQE4HL4Z4FP7URCCKZTLAOLANFBVFHS/

I've checked 'AmbientCapabilities=CAP_SYS_PTRACE'.
Unfortunately, it didn't help.

The actual gained capabilities are:

grep Cap /proc/"$(pgrep gssproxy)"/status
CapInh: 0000000000080000
CapPrm: 0000000000000000
CapEff: 0000000000000000
CapBnd: 0000003fffffffff
CapAmb: 0000000000000000

Why this happens.
According to capabilities(7):

Effect of user ID changes on capabilities
       To preserve the traditional semantics for transitions between 0 and
       nonzero user IDs, the kernel makes the following changes to a
       thread's capability sets on changes to the thread's real, effective,
       saved set, and filesystem user IDs (using setuid(2), setresuid(2), or
       similar):
       1. If one or more of the real, effective or saved set user IDs was
          previously 0, and as a result of the UID changes all of these IDs
          have a nonzero value, then all capabilities are cleared from the
          permitted, effective, and ambient capability sets.

Hence, it needs to raise CAP_SYS_PTRACE right after privileges dropping.
The fix plan is:
1) set SECBIT_KEEP_CAPS before UID switch to retain capabilities in its permitted and effective sets;
2) after switch UID clearing of bounding set capabilities;
3) dropping all capabilities, but CAP_SYS_PTRACE in permitted and effective sets;

Commit f03d9b74 fixes this issue

Commit 2ca45253 fixes this issue
Metadata
None
None
None
None
None
None
None
None
Related Pull Requests
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.