Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 162452 - sudo gives Tons of errors after disabling SELinux
Summary: sudo gives Tons of errors after disabling SELinux
Alias: None
Product: Fedora
Classification: Fedora
Component: libselinux
Version: 4
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2005-07-05 02:07 UTC by Luis A. Florit
Modified: 2007-11-30 22:11 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2006-01-06 15:46:46 UTC

Attachments (Terms of Use)

Description Luis A. Florit 2005-07-05 02:07:15 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050513 Galeon/1.3.21

Description of problem:
Sorry if this is not a bug, but after searching in Google with no results, 
I posted this in and noone answered. So, I assume it is a bug.

I installed FC4 with SELinux enabled, and then I turned it OFF, since 
I don't run any server (and I have no experience with SELinux).
I use NFS, with a non-standard HOME directory.

The system is working fine, but when running 'sudo rpm -Uvh <package>' 
I get, just before installing the package, TONS of errors like:
/etc/selinux/targeted/contexts/files/file_contexts: line 1712 has invalid context system_u:object_r:texrel_shlib_t
/etc/selinux/targeted/contexts/files/file_contexts.homedirs: line 56 has invalid context root:object_r:user_home_dir_t

One error for each line in files file_contexts(.homedirs), so hundreds 
of errors! After all this, the package is correctly installed.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
Just running "sudo rpm -Uvh <package>".

Additional info:

Comment 1 Daniel Walsh 2005-07-05 11:07:09 UTC
This looks like rpm is not checking if SELinux is enabled?

Comment 2 Luis A. Florit 2005-07-05 23:58:07 UTC
Well, I know nothing about SELinux, but it appears to behave like so.
I have another almost identical machine that I installed without SELinux from
the beginning, and it works perfect.

Comment 3 Luis A. Florit 2005-07-06 19:16:33 UTC
This is important: 
The same operation when doing by a local user (in particular, with a standard
$HOME) gives no error.

Comment 4 Jeff Johnson 2005-08-27 02:37:25 UTC
rpm performs this check to see if SELinux is enabled:

        ts->selinuxEnabled = is_selinux_enabled();

AFAIK, that is still the libselinux API to be used.

Comment 5 Daniel Walsh 2006-01-06 13:30:34 UTC
        ts->selinuxEnabled = is_selinux_enabled() >0;

Should be used.

Comment 6 Jeff Johnson 2006-01-06 14:00:57 UTC
Bzzzt! Why? Every usage of ts->selinuxEnabled checks for > 0, the variable
conatins exactly (the non-boolean) value returned from libselinux.

"Tons of errors" after an upgrade to a broken policy package is the problem, not rpm.

Comment 7 Daniel Walsh 2006-01-06 14:34:17 UTC
Ok, but rpm should not be calling matchpathcon if selinux is disabled.

Comment 8 Jeff Johnson 2006-01-06 14:41:55 UTC
Bzzzt! Then file a different bug.

The intent was to permit verification of file context policy against installed
selinux xattrs with selinux disabled for QA purposes. That was successfully
and correctly implemented.

The addition of matchpathcon for MLS purposes has been imperfectly implemented
in the Red Hat rpm. Which is why the patch is not upstream.

Comment 9 Daniel Walsh 2006-01-06 15:13:14 UTC
The bug in setrans which you are refering to has been fixed.  What other part of
matchpathcon is broken?

Comment 10 Jeff Johnson 2006-01-06 15:25:20 UTC
If the underlying cause of "tons of errors" is the "bug in setrans", then this bug should
be closed.

If matchpathcon() should not be called if selinux is disabled, then another bug should be
added against rpm, as that is not the current behavior (nor was it the original implementation
intent) in rpm afaik.

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