Miroslav, can you take a look?

Adding also Lukas Vrabec, fedora maintainer.

Hi, 

Do the sanlock daemon require DAC_OVERRRIDE capability? We removed from distribution SELinux policy quite lot of allow rules allowing DAC_OVERRIDE capability for the deamon. In most cases it's issue on the application/daemon side, not SELinux side. For more info see following article: 
https://lukas-vrabec.com/index.php/2018/07/03/why-do-you-see-dac_override-selinux-denials/

I can help you to identify which file has too tight unix permissions please turn on full auditing on audit daemon and reproduce the scenario:
https://lukas-vrabec.com/index.php/2018/07/16/how-to-enable-full-auditing-in-audit-daemon/

Thanks,
Lukas.

Thanks Lukas, by default sanlock is using "sanlock" (179) for both its uid and gid.  From reading the links, it sounds like sanlock should instead use gid of "root", is that correct?

Nir, set gname = root in sanlock.conf to try this and see if it works.

David, 

Yes agree, apache and other services using the same fix.

Nir, can you confirm that using group "root" will not upset things on nfs with root squash?

----
type=PROCTITLE msg=audit(07/17/2018 09:51:29.082:1878) : proctitle=/usr/sbin/sanlock daemon 
type=PATH msg=audit(07/17/2018 09:51:29.082:1878) : item=0 name=/var/run/sanlock/ inode=444150 dev=00:16 mode=dir,755 ouid=sanlock ogid=sanlock rdev=00:00 obj=system_u:object_r:sanlock_var_run_t:s0 nametype=PARENT cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 
type=CWD msg=audit(07/17/2018 09:51:29.082:1878) : cwd=/ 
type=SYSCALL msg=audit(07/17/2018 09:51:29.082:1878) : arch=x86_64 syscall=openat success=no exit=EACCES(Permission denied) a0=0xffffff9c a1=0x7fff47fc0630 a2=O_WRONLY|O_CREAT|O_CLOEXEC a3=0x1a4 items=1 ppid=1 pid=15264 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=sanlock exe=/usr/sbin/sanlock subj=system_u:system_r:sanlock_t:s0-s0:c0.c1023 key=(null) 
type=AVC msg=audit(07/17/2018 09:51:29.082:1878) : avc:  denied  { dac_override } for  pid=15264 comm=sanlock capability=dac_override  scontext=system_u:system_r:sanlock_t:s0-s0:c0.c1023 tcontext=system_u:system_r:sanlock_t:s0-s0:c0.c1023 tclass=capability permissive=0 
----

Nir, have you been able to check if setting "gname = root" in sanlock.conf fixes the problem?  If so, then I'll check in the fix to the code to use root as the default group.

Sorry, I did not have time to check this yet.

Can you explain this change? why would we want to run sanlock with group root?

I would like to run sanlock with group sanlock, and change selinux policy so
sanlock can access its own pid file.

Apparently group root is the right way to do this according to the experts, but I don't understand it well enough to explain myself.  The links in comment 3 explain it pretty well.

(In reply to David Teigland from comment #10)
Base on:
https://lukas-vrabec.com/index.php/2018/07/03/why-do-you-see-dac_override-selinux-denials/

The problem is:

1. sanlock running as root, before dropping permissions
2. sanlock try to write to /var/run/sanlock/sanlock.pid, owned by sanlock:sanlock

So why not change /var/run/sanlock/sanlock.pid ownership to root:root?

I tried this patch on RHEL 7.5:

diff --git a/src/lockfile.c b/src/lockfile.c
index 5a2518e..e837d49 100644
--- a/src/lockfile.c
+++ b/src/lockfile.c
@@ -89,13 +89,6 @@ int lockfile(const char *dir, const char *name, int uid, int gid)
                goto fail;
        }
 
-       rv = fchown(fd, uid, gid);
-       if (rv < 0) {
-               log_error("lockfile fchown error %s: %s",
-                         path, strerror(errno));
-               goto fail;
-       }
-
        return fd;
  fail:
        close(fd);


With this patch:

# ls -lhZ /run/sanlock/
-rw-r--r--. root    root    system_u:object_r:sanlock_var_run_t:s0 sanlock.pid
srw-rw----. sanlock sanlock system_u:object_r:sanlock_var_run_t:s0 sanlock.sock

Did not test on Fedora 28 yet (environment issue).

Nir, that looks good to me if it resolves the issue.

(In reply to David Teigland from comment #12)
Ok, I'll test it and post a patch to sanlock.

Nir, is this still a problem?

I tested this patch on Fedora 28, and it fixes the issue.
https://lists.fedorahosted.org/archives/list/sanlock-devel@lists.fedorahosted.org/thread/ZTG4E264IMHVFSVDKDPA6HSGBUFBQ2JI/

Milos, can you review this patch?

LGTM.

David, we are still missing the fedora package with the fix, right?

sanlock-3.6.0-8.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-a27b970ddf

sanlock-3.6.0-4.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2019-ea4ecdc166

sanlock-3.6.0-8.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-a27b970ddf

sanlock-3.6.0-4.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-ea4ecdc166

sanlock-3.6.0-4.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.

sanlock-3.6.0-8.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.

sanlock-3.6.0-8.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.