On Wed, 2004-05-05 at 02:12, Bob Gustafson wrote:
> [root@hoho2 user1]# yum install setools*
Sorry, should have escaped the *, otherwise the shell may expand it for
you if there are any matching files in the current working directory,
and then yum won't be happy.
> A typical bunch of diagnostics looked like this:
>
> Cleaning out /tmp
> /usr/sbin/setfiles: conflicting specifications for
> /lib/modules/2.6.3-2.1.253.2.1custom/modules.dep and
> /lib/modules/2.6.5-1.327/build/include/config/MARKER, using
> system_u:object_r:modules_dep_t.
>
> /usr/sbin/setfiles: conflicting specifications for
> /usr/src/redhat/BUILD/ooo-build-1.1.53pre/build/OOO_1_1_1/setup2/
> unxlngi4.pro/bin/tplx64533.res and
> /var/tmp/openoffice.org-1.1.1-root/usr/lib/ooo-1.1/program/
> resource/tplx64533.res, using system_u:object_r:src_t.
>
> /usr/sbin/setfiles: conflicting specifications for
> /usr/src/redhat/BUILD/ooo-build-1.1.53pre/build/OOO_1_1_1/
> setup2/unxlngi4.pro/bin/tplx64590.res and
> /var/tmp/openoffice.org-1.1.1-root/usr/lib/ooo-1.1/program/resource/
> tplx64590.res, using system_u:object_r:src_t.
>
> There is a pattern here, but I can't express it in fixable terms.
A "conflicting specifications" warning means that setfiles thinks that
the two pathnames are multiple hard links to the same inode, which can
only have a single security context, but the two pathnames match entries
in file_contexts that have different security contexts, so there is a
conflict. setfiles will still label the inode (based on the ordering in
file_contexts, with later entries taking precedence, unless there is an
explicit entry for the complete pathname), but it is warning that there
is an ambiguity in the specification. Repeatedly relabeling won't help,
as the conflict will remain until:
- the conflicting hard link is removed, or
- the file_contexts configuration is altered to explicitly indicate that
both pathnames should have the same context, typically by adding
explicit entries for the conflicting files.
> System Tools -> Sound Card Detection -> play sound
>
> May 4 19:43:51 hoho2 udev[3472]: creating device node '/udev/audio'
> May 4 19:43:51 hoho2 udev[3479]: creating device node '/udev/adsp'
> May 4 19:43:51 hoho2 kernel: audit(1083717831.232:0): avc: denied
> relabelfrom } for pid=3485 exe=/sbin/restorecon name=mixer dev=sda2
> ino=5374112 scontext=system_u:system_r:udev_t
> tcontext=system_u:object_r:device_t tclass=lnk_file
>
> May 4 19:43:51 hoho2 kernel: audit(1083717831.232:0): avc: denied {
> relabelto } for pid=3485 exe=/sbin/restorecon name=mixer dev=sda2
> ino=5374112
> scontext=system_u:system_r:udev_t tcontext=system_u:object_r:sound_device_t
> tclass=lnk_file
>
> Seems to be a problem with the sound card stuff - even though it is not
> enforcing at the moment. It worked before SELinux.
Not sure why udev is relabeling a symlink. Dan?
Make sure that you are working with the latest policy, i.e. yum update
policy.
--
Stephen Smalley <sds@xxxxxxxxxxxxxx>
National Security Agency
