Bug 191401 - /var as a mount-point causes errors
Summary: /var as a mount-point causes errors
Alias: None
Product: Fedora
Classification: Fedora
Component: pam   
(Show other bugs)
Version: 5
Hardware: All Linux
Target Milestone: ---
Assignee: Tomas Mraz
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2006-05-11 17:30 UTC by Chris Adams
Modified: 2007-11-30 22:11 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-08-08 16:01:23 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Chris Adams 2006-05-11 17:30:46 UTC
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
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).

Comment 1 Daniel Walsh 2006-05-11 17:48:23 UTC
I would say this is more of an installation problem.  Since the install is not
labeling the directory prooperly.

Comment 2 Chris Adams 2006-05-11 18:06:25 UTC
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).

Comment 3 Tomas Mraz 2006-05-16 18:35:52 UTC
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.

Comment 4 Tomas Mraz 2006-05-18 15:45:43 UTC
I'll update PAM in FC 5 soon.

Comment 5 Fedora Update System 2006-08-01 18:38:03 UTC
pam- 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.

Comment 6 Fedora Update System 2006-08-08 15:12:23 UTC
pam- 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.

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