Bug 162452 - sudo gives Tons of errors after disabling SELinux
sudo gives Tons of errors after disabling SELinux
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: libselinux (Show other bugs)
4
i386 Linux
medium Severity low
: ---
: ---
Assigned To: Daniel Walsh
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-07-04 22:07 EDT by Luis A. Florit
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-01-06 10:46:46 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Luis A. Florit 2005-07-04 22:07:15 EDT
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 Fedoraforum.org 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):
selinux-policy-targeted-1.23.18-17.noarch.rpm

How reproducible:
Always

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

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

Comment 2 Luis A. Florit 2005-07-05 19:58:07 EDT
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 15:16:33 EDT
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-26 22:37:25 EDT
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 08:30:34 EST
        ts->selinuxEnabled = is_selinux_enabled() >0;

Should be used.
Comment 6 Jeff Johnson 2006-01-06 09:00:57 EST
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 09:34:17 EST
Ok, but rpm should not be calling matchpathcon if selinux is disabled.
Comment 8 Jeff Johnson 2006-01-06 09:41:55 EST
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 10:13:14 EST
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 10:25:20 EST
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.