Bug 478494 - shadow-util should require policycoreutils
shadow-util should require policycoreutils
Product: Fedora
Classification: Fedora
Component: shadow-utils (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Peter Vrabec
Fedora Extras Quality Assurance
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2008-12-30 20:42 EST by Steve Adams
Modified: 2009-04-14 06:29 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-04-14 06:29:29 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
proposed patch (862 bytes, patch)
2009-01-07 04:46 EST, Adam Tkac
no flags Details | Diff

  None (edit)
Description Steve Adams 2008-12-30 20:42:47 EST
It is possible to
  rpm -e policycoreutils
leaving shadow-utils spitting out "Failed to exec" errors about the missing executables.

This dependency should be made explicit so that policycoreutils cannot be removed.
Comment 1 Peter Vrabec 2009-01-05 05:54:03 EST
I don't have any problems to use shadow-utils, after I removed policycoreutils.

Could you send me the steps to reproduce the problem, please.
Comment 2 Peter Vrabec 2009-01-05 08:19:53 EST
OK, I see it. (from Steve's email)

usermod uses /sbin/restorecon, so there is a need for Requires.
Comment 3 Fedora Update System 2009-01-05 08:22:09 EST
shadow-utils-4.1.2-9.fc10 has been submitted as an update for Fedora 10.
Comment 4 Fedora Update System 2009-01-07 04:27:43 EST
shadow-utils-4.1.2-9.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 5 Adam Tkac 2009-01-07 04:45:12 EST
With this change you have to have policycoreutils and other SELinux related
packages installed on system without SELinux. SELinux is optional part of
system so I recommend do not add policycoreutils to Requires.

I think better solution is to check if restorecon is present and execute it
conditionally. With this approach no warning will be printed and you don't have
to install SELinux stuff on non-selinux systems. I will attach proposed patch.
Comment 6 Adam Tkac 2009-01-07 04:46:47 EST
Created attachment 328361 [details]
proposed patch

Proposed patch. Note that I didn't test/compile it, it is quite clear.
Comment 7 Daniel Mach 2009-01-20 03:59:05 EST
I agree with Adam's comment #5.
Peter, can we avoid dependency on policycoreutils?
Comment 8 Peter Vrabec 2009-04-06 11:05:13 EDT
Daniel, what do you think about this? I'm working on new release for F11 and I would really like to have nice solution.
Comment 9 Daniel Walsh 2009-04-06 11:11:17 EDT
Fine, although I would print a warning message.
Comment 10 Peter Vrabec 2009-04-07 04:53:10 EDT
hey, I have different way to fix it. It's related to your patch Daniel. So please let me know if I'm wrong because I'm gonna change the logic little bit.

usermod.c:selinux_update_mapping ()

if (dflg || *user_selinux) {
    /sbin/restorecon -R -R user_home

Why there is OR in "if" condition?
Why do we call genhomedir and restorecon in case user_selinux is not changed?
There are two options:
1. dflg - homedir is changed, but not moved!!
2. dflg and mflg - homedir is changed and moved.
I think we can ignore both cases from selinux perspective unless user_selinux is changed.

I suggest this change:
if (*user_selinux) {
    /sbin/restorecon -F -R user_home

What will we fix?
* this bug, because it won't scream "Failed to exec" on user
* it will call genhomedircon and restorecon only when it's necessary. If they are missing there will be a warning and "Failed to exec"
* shadow-utils won't require policycoreutils, which would be great.
Comment 11 Daniel Walsh 2009-04-07 10:15:22 EDT
When you select a different Directory then the default, there is a good chance that it is not labelled correctly.  So genhomedircon would notice the new directory as well as a new label for a user.  genhomedircon responsibility it to try to figure out which directories contain users accounts and which users are using special SELinux user types.

We are starting to move away from variable labeling in the homedirectory except for special user cases.  I am also looking to add new tools to semanage to allow users to specify alternate directories for user accounts rather then running genhomedircon within the useradd/usermod functionality.

So I think we might want to think about removing this functionality and just running the restorecon command.
Comment 12 Peter Vrabec 2009-04-14 06:29:29 EDT
Fixed again in rawhide(F11) - shadow-utils-4.1.3-1.fc11. 
/sbin/restorecon and /usr/sbin/genhomedircon are not called in usermod.

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