Bug 1737550
| Summary: | Need a label created for RHDS tmpfs directory | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | mreynolds |
| Component: | selinux-policy | Assignee: | Zdenek Pytela <zpytela> |
| Status: | CLOSED ERRATA | QA Contact: | Milos Malik <mmalik> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 8.3 | CC: | ds-qe-bugs, jpazdziora, lvrabec, mhonek, mmalik, plautrba, ssekidde, vashirov, zpytela |
| Target Milestone: | rc | Keywords: | Patch, Triaged |
| Target Release: | 8.2 | Flags: | pm-rhel:
mirror+
|
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-04-28 16:40:41 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
What would also work would be a label for /dev/shm/dirsrv/ then we could stick the slapd-INSTANCE directories under that directory. Whatever is easier for you. SELinux policy now defines following file context patterns: # semanage fcontext -l | grep /dev/shm /dev/shm directory system_u:object_r:tmpfs_t:s0 /dev/shm/.* all files <<None>> /dev/shm/lldpad.* regular file system_u:object_r:lldpad_tmpfs_t:s0 /dev/shm/mono.* all files system_u:object_r:user_tmp_t:s0 /dev/shm/pulse-shm.* all files system_u:object_r:user_tmp_t:s0 /dev/shm/squid-* regular file system_u:object_r:squid_tmpfs_t:s0 # The warning message appears, because an appropriate file context pattern for slapd is missing. But SELinux policy defines that a newly created file in /dev/shm directory gets the slapd_tmpfs_t label if the process, which created the file, runs under slapd_t context: # sesearch -t tmpfs_t -T | grep slapd type_transition slapd_t tmpfs_t:file slapd_tmpfs_t; # The output you provided: # ls -laZ /dev/shm/ drwxrwx---. 2 dirsrv dirsrv unconfined_u:object_r:user_tmp_t:s0 40 Aug 5 10:45 slapd-test # proves that the process which created the /dev/shm/slapd-test file was not running under slapd_t context. Can you find out what context has the process which creates the /dev/shm/slapd-test file ? (I suspect that the process runs under unconfined_t context, but I want to be sure). First thanks for the quick response! Okay, so I modified my patch to create /dev/shm/dirsrv/ during the RPM installation, but I still see the same context: ls -laZ /dev/shm/dirsrv/ total 0 drwxr-xr-x. 2 root root unconfined_u:object_r:user_tmp_t:s0 40 Aug 5 16:18 . FYI, previously an installation script, run as root, was creating /dev/shm/slapd-INSTANCE, and then trying to run restorecon failed as previously described. Now, in the specfile I create /dev/shm/dirsrv/ and the install script adds the slapd-INSTANCE directories underneath it. So getting back to your question, I am not sure what context the RPM is using. Other directories created during the RPM installation show dirsrv contexts/labels: # ls -laZ /var/run/dirsrv/ drwxrwx---. 2 dirsrv dirsrv system_u:object_r:dirsrv_var_run_t:s0 280 Aug 6 09:38 . # ls -laZ /var/log/dirsrv/ drwxr-xr-x. 8 root root system_u:object_r:dirsrv_var_log_t:s0 4096 Aug 5 16:18 . Then when we start an instance it rights this semaphore file to /dev/shm: -rw-------. 1 dirsrv dirsrv system_u:object_r:dirsrv_tmpfs_t:s0 32 Aug 5 10:29 sem.slapd-replica.stats FYI, that label is "dirsrv_tmpfs_t", not "slapd_tmpfs_t" Anyway I'm not sure how to get the context the RPM installation process is using. Is there a specific command you need me to run to gather information? Thanks, Mark Hi mreynolds, The main issue as Milos mentioned is to identify which process created /dev/shm. Would it be possible that RHDS will created that directory during startup? It should fix the issue. (In reply to Lukas Vrabec from comment #4) > Hi mreynolds, > > The main issue as Milos mentioned is to identify which process created > /dev/shm. Would it be possible that RHDS will created that directory during > startup? > > It should fix the issue. I don't know what creates /dev/shm, I thought it was there by default. I would like the RPM package to create /dev/shm/dirsrv/ with the correct label, but when it does create it has the wrong label. If I have the process create the directory at process startup (running as root) it still has the wrong label (although this is not how it should work anyway). To reiterate, I need the RPM install to create /dev/shm/dirsrv/ with correct label. Then each instance of the process would create: /dev/shm/dirsrv/slapd-INSTANCE/ and run restorecon during startup. From what I understand is I just need a label for /dev/shm/dirsrv/ and I should be good to go. Thanks, Mark Sorry everyone I need to reopen this. I should have stuck with my original plan. What I finally asked for was a label for /dev/shm/dirsrv/*, but this subdirectory approach is not working for the feature that was using it. I need to do what I originally stated in the bug description. I need a dirsrv_tmpfs_t label for directories matching: /dev/shm/slapd-*/ This also means the old label for /dev/shm/dirsrv/ can be removed. I also need this to get into 8.3 if possible, otherwise we will have to push back our RPL feature. Thanks again! I'm not sure I understand what the current plan is, but creating directories in /dev/shm via rpm transaction is bound to fail in containers (the build container and the runtime container are completely different containers, and /dev/shm is obviously not part of the image), and on host after reboot. Specifying locations under /dev/shm in %files does not achieve what you expect. The fact that rpm manages to place the file to the directory upon yum/dnf installation does not mean that the directory will persist over reboot. (In reply to Jan Pazdziora from comment #20) > I'm not sure I understand what the current plan is, but creating directories > in /dev/shm via rpm transaction is bound to fail in containers (the build > container and the runtime container are completely different containers, and > /dev/shm is obviously not part of the image), and on host after reboot. > Specifying locations under /dev/shm in %files does not achieve what you > expect. The fact that rpm manages to place the file to the directory upon > yum/dnf installation does not mean that the directory will persist over > reboot. Right, this is the exact problem I am trying to fix. :-) When our server starts up it creates a sub-directory under /dev/shm/dirsrv/. I incorrectly had the rpm create /dev/shm/dirsrv/, then at server startup it would create another directory: /dev/shm/dirsrv/slapd-INSTANCE/ But after a reboot /dev/shm/dirsrv is removed and it was causing the server to fail to startup because it couldn't create the slapd-INSTANCE directory. There were other odd behaviors as well. So the entire approach was flawed (completely my fault). So, all we need is to create the slapd_INSTANCE directory directly under /dev/shm (forgetting the /dirsrv sub-directory). This works, it solves all the reboot and start up issues, but we now need selinux rules/labels to allow the server to create directories like: /dev/shm/slapd-INSTANCE (/dev/shm/slapd-*) Also for containers we don't create that directory under /dev/shm at all (fyi) I hope that clears things up. Thanks, Mark I'm not sure I understand why the server cannot create both /dev/shm/dirsrv and the /dev/shm/dirsrv/slapd-INSTANCE upon startup. It might keep things a bit more tidy. I've actually hit the problem in rawhide containers where the /dev/shm/dirsrv was created as root:root with permissions (IIRC) rwxrwx---, so the dirsrv user then couldn't access the slapd-INSTANCE subdirectory. However, today the rawhide container works again so I assume new build in rawhide has the logic fixed. (In reply to Jan Pazdziora from comment #22) > I'm not sure I understand why the server cannot create both /dev/shm/dirsrv > and the /dev/shm/dirsrv/slapd-INSTANCE upon startup. It might keep things a > bit more tidy. > > I've actually hit the problem in rawhide containers where the > /dev/shm/dirsrv was created as root:root with permissions (IIRC) rwxrwx---, > so the dirsrv user then couldn't access the slapd-INSTANCE subdirectory. > However, today the rawhide container works again so I assume new build in > rawhide has the logic fixed. I temporarily stopped setting the nsslapd-db-home-directory to /dev/shm/dirsrv in the latest build because it was breaking the server in VMs, containers, FreeIPA CI, and on Debian (works on Fedora until you reboot the system). Once, and if, I can get the new label created I will start setting nsslapd-db-home-directory back to /dev/shm 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-2020:1773 |
Description of problem: When our server (Red Hat Directory Server) creates a directory under /dev/shm it has the wrong label. In this case that directory is: /dev/shm/slapd-test # ls -laZ /dev/shm/ drwxrwx---. 2 dirsrv dirsrv unconfined_u:object_r:user_tmp_t:s0 40 Aug 5 10:45 slapd-test Trying to do a restorecon on this directory reports: Warning no default label for /dev/shm/slapd-test Other files created by the server under /dev/shm do have the correct label: -rw-------. 1 dirsrv dirsrv system_u:object_r:dirsrv_tmpfs_t:s0 32 Aug 5 10:29 sem.slapd-replica.stats Something else that is important to mention is that the 389-ds-base package can create many directories under /dev/shm with the following pattern: /dev/shm/slapd-<COULD BE ANY VALUE> /dev/shm/slapd-test/ /dev/shm/slapd-another-test/ Any help would be appreciated. Thanks!