[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [kay.sievers@vrfy.org]

On Mon, 2006-02-06 at 10:46 -0500, Bill Nottingham wrote:
> Some questions from the upstream udev maintainer... from reading
> it, the media  stuff is because CDROMs, etc. have a different file
> type, and the defaultfile context needs set in everything that
> creates devices. Is that correct?

Dan Walsh wrote the original udev SELinux support, so take this with a
grain of salt, but I think that you are correct.  The usual file
contexts approach of labeling based on pathname regex wasn't sufficient
for removable media, so Dan introduced the specialized media handling.  

On Kay's selinux_init question:

> Can't we move the selinux_init() called from every event process
> to the single main daemon init? I don't know how expensive that is,
> nor do I know if selinux is fine with that, but if we can make that
> faster it would be better...

The expensive part of selinux_init is matchpathcon_init, but that should
be somewhat alleviated by the introduction of matchpathcon_init_prefix
so that only the necessary file_contexts entries are processed and the
libselinux changes to perform lazy canonicalization of the security

The matchpathcon_init has to be done in the process that performs the
subsequent matchpathcon calls, as it populates an in-memory data
structure used by matchpathcon.  Conceivably, both the
matchpathcon_init_prefix and the later matchpathcon calls could be done
in the parent daemon and the children could receive the appropriate
context info from the parent via a pipe or commandline argument, but
someone would have to work out the details there.

The rest of selinux_init is just saving the old file creation context
(if one was previously set) so that it can be restored later.  In
practice, I suspect that this is always NULL for udev, and we could
"optimize" this away, but it is safer to always save-and-restore it, and
that isn't the expensive part.

> And the get_media() in udev_selinux.c for every block device seems
> a bit weird. Do you know if this really needed? What about scsi then?
> I've added the IDE stuff to sysfs in 2.6.15, so we should at least
> use the file there...

Not sure - I'll defer to Dan on this.

Stephen Smalley
National Security Agency

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]