Russell Coker writes:
> On Tue, 28 May 2002 15:04, Stephen Smalley wrote:
> > On Fri, 24 May 2002, Russell Coker wrote:
> > > On my systems I have devfsd do most of the device node labelling.
> > >
> > > I have noticed that often the system_u:object_r:fixed_disk_device_t
> > > labels (for /dev/ide/host0/bus0/target0/lun0/*) will get changed to
> > > system_u:object_r:devfs_t (the default context for devfs).
> > >
> > > It doesn't happen to the device node for the entire file system
> > > /dev/ide/host0/bus0/target0/lun0/disc and the device node
> > > /dev/ide/host0/bus0/target0/lun0/part5 (an extended partition).
> > >
> > > I believe that this is not a user-land issue, and it's something in the
> > > kernel (but I have not proven this yet).
> > >
> > > Also it seems to happen more often when under load (setfiles on the root
> > > file system usually does the job).
> >
> > This could happen if a devfs entry is evicted from the dcache and is later
> > looked up again, causing the security context to be re-acquired from the
> > devfs_contexts configuration. Doesn't this issue also arise for the
> > ownership and mode on devfs entries when they are managed by devfsd?
>
> No! Devfs preserves the results of chmod/chown operations until the
> next reboot.
Or until the entry is unregistered (and if you haven't configured
devfsd to restore permissions).
> I'm surprised though, I thought that devfs entries would be locked
> in the dcache...
Nope. Devfs currently uses it's own backing store (i.e. file tree),
thus devfs dentries may be freed. That's going to change in 2.5,
however.
Note: I'm not subscribed to the (closed) SE Linux list so I've removed
it from the Cc: line.
Regards,
Richard....
Permanent: rgooch@xxxxxxxxxxxxx
Current: rgooch@xxxxxxxxxxxxxxx
|