Bug 1186422 - libsemanage calls mkdir() without setting the umask properly
Summary: libsemanage calls mkdir() without setting the umask properly
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libsemanage
Version: 7.1
Hardware: All
OS: Linux
Target Milestone: rc
: ---
Assignee: Vit Mojzis
QA Contact: Jan Zarsky
Depends On:
TreeView+ depends on / blocked
Reported: 2015-01-27 16:16 UTC by Jakub Hrozek
Modified: 2018-12-18 01:39 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1371389 (view as bug list)
Last Closed: 2018-10-30 09:35:42 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2018:3088 0 None None None 2018-10-30 09:36:06 UTC

Description Jakub Hrozek 2015-01-27 16:16:06 UTC
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:

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:

Comment 2 Roland Mainz 2015-01-27 16:39:56 UTC
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)
-- snip --
... and you're done...

Comment 4 Petr Lautrbach 2015-07-21 14:49:59 UTC
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.

Comment 7 Jan Zarsky 2016-08-30 06:49:35 UTC
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 )

Comment 16 errata-xmlrpc 2018-10-30 09:35:42 UTC
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.


Comment 17 Adam Williamson 2018-12-18 01:39:07 UTC
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:


may not be needed any more? It has caused us some issues lately.

Note You need to log in before you can comment on or make changes to this bug.