Bug 191401
| Summary: | /var as a mount-point causes errors | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Chris Adams <linux> |
| Component: | pam | Assignee: | Tomas Mraz <tmraz> |
| Status: | CLOSED ERRATA | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 5 | CC: | dwalsh, katzj |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2006-08-08 16:01:23 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
I would say this is more of an installation problem. Since the install is not labeling the directory prooperly. It isn't really just an install problem; if a relabel needed to change /var, the same issue would arise. The only way I see to access the underlying directory under a mount point is to bind mount the parent filesystem somewhere (since bind mounts are not recursive). However, looking at it more, I think the problem is with pam_console_apply. It should not be trying to set permissions based on console users before the system is done booting (before filesystems are mounted). Maybe there needs to be a "booting up" flag that skips that step, or it should check the runlevel (or udev should somehow be configured to not call it during boot). pam_console_apply is actually called with '-r' so it should reset the permissions as if no user is logged on console. However it unnecesarily opens the console lock file in /var. Fixed in rawhide. I'll update PAM in FC 5 soon. pam-0.99.5.0-5.fc5 has been pushed for fc5, which should resolve this issue. If these problems are still present in this version, then please make note of it in this bug report. pam-0.99.5.0-5.fc5 has been pushed for fc5, which should resolve this issue. If these problems are still present in this version, then please make note of it in this bug report. |
If I create /var as a separate mount point (which I do on servers), the underlying directory on the root filesystem does not get labeled correctly (during install or during a relabel operation). It gets system_u:object_r:file_t instead of system_u:object_r:var_t. The root of the /var filesystem gets labeled right, but apparently something is trying to access /var during boot before /var is mounted. During boot, I get 230 messages: audit(1147367670.617:2): avc: denied { search } for pid=534 comm="pam_console_app" name="var" dev=dm-0 ino=47105 scontext=system_u:system_r:pam_console_t:s0-s0:c0.c255 tcontext=system_u:object_r:file_t:s0 tclass=dir I'm not sure what program is actually trying to run here. If I boot single user, umount /var, and chcon -t var_t /var, I don't get these errors on future boots. I'm listing this against selinux-policy more for a lack of a better place. I'm not really sure where this belongs (I guess it is more of a startup or pam_console bug that is trying to access /var during boot).