Hide Forgot
Description of problem: On some places, like semanage_copy_dir(), libsemanage creates a directory with certain permissions using mkdir(path, 0700) and relies on the permissions being correct. But it never sets or checks the umask, so programs using libsemanage with a very restrictive umask (like deamons) might end up creating the directory with wrong permissions. Version-Release number of selected component (if applicable): How reproducible: always Steps to Reproduce: 1. set a restrictive umask 2. call libsemanage functions 3. ls -ld /etc/selinux/targeted/modules/active Actual results: clobbered permissions Expected results: permissions are as libsemanage expects them. Additional info:
Basically libsemanage should fix the permissions after the |mkdir()| call like the mkdir(1) code in https://searchcode.com/codesearch/view/5481405/ line 160 does. An even better way would be to use |mkdirat()| and |fchmodat()| to prevent attacks which swap the parent directory, e.g. you |dirfd = open(parentdirname, O_SEARCH)| and then do |mkdirat(dirfd, ...| and |fchmodat(dirfd, ...)|. Note that Linux does not have POSIX |O_SEARCH| but aliasing it to |O_PATH| works fine, e.g. do this ... -- snip -- #ifndef O_SEARCH #define O_SEARCH (O_PATH) #endif -- snip -- ... and you're done...
It needs to be fixed and discussed upstream first. When an user sets umask, she could have a reason for that. I,m postponing this bug to 7.3. Sorry.
Described reproducer causes clobbered permissions on RHEL-7.2 and older, on RHEL-7.3 with libsemanage-2.5-3.el7.x86_64 it passes, the permissions stays the same. So this bug is fixed for RHEL-7.3. (There is clone of this bug for RHEL6: https://bugzilla.redhat.com/show_bug.cgi?id=1371389 )
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2018:3088
See also (RIP the 'See also' field, apparently a casualty of the Bugzilla 5 migration :<): https://bugzilla.redhat.com/show_bug.cgi?id=1654537 and https://bugzilla.redhat.com/show_bug.cgi?id=1644919 . Now this has been fixed, perhaps this chunk of sssd: https://pagure.io/SSSD/sssd/blob/945865a/f/src/providers/ipa/selinux_child.c#_144 may not be needed any more? It has caused us some issues lately.