| Summary: | xguest broken by authconfig | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Jonathan Underwood <jonathan.underwood> |
| Component: | xguest | Assignee: | Lukas Vrabec <lvrabec> |
| Status: | CLOSED WONTFIX | QA Contact: | Milos Malik <mmalik> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 6.0 | CC: | mmalik, rvokal |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2016-11-02 17:30:25 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
Jonathan Underwood
2011-07-27 12:48:02 UTC
This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unfortunately unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux. If you would like it considered as an exception in the current release, please ask your support representative. Actually, I am less sure it's a pam issue - perhaps it's the location of the xguest home directory entry. Would it not be better to create the home directory outside of /home eg. in /var/lib or somesuch, especially given it's polyinstantiated on login anyway? I have actually tried removing the xguest account and recreating it with home defined under /usr/local/home just to see, but that didn't work. Actually I just did this: userdel xguest useradd -c "Guest" -Z xguest_u xguest -U -u 500 -m -d /usr/local/xguest || semanage login -a -S targeted -s xguest_u xguest || semanage login -m -S targeted -s xguest_u xguest and then found that the xguest account worked. However, trying the same thing but with the home directory as /var/lib/xguest didn't work, presumably because of this: libsemanage.get_home_dirs: xguest homedir /var/lib/xguest or its parent directory conflicts with a file context already specified in the policy. This usually indicates an incorrectly defined system account. If it is a system account please make sure its uid is less than 500 or its login shell is /sbin/nologin. So, I suppose my question and RFE is: can the xguest home directory be moved out of /home and into /var somehow? Having a directory for xguest under /home doesn't work if home directories are mounted over nfs, which is a common use case. Try /var/lib/home/xguest The problem is tools expect the directory above xguest to be labeled home_t, and when they see a standard directory label they will not change it. Maybe /var/run/home/xguest would be a better location since /var/run is temporary. I am not sure this would work, but might be worth a try. Well, interestingly:
1) using /var/run/home/xguest didn't work, and audit2why gives a few of these:
type=AVC msg=audit(1311872712.517:43592): avc: denied { mounton } for pid=2826 comm="gdm-session-wor" path="/var/run/home/xguest" dev=sda3 ino=6291930 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_run_t:s0 tclass=dir
Was caused by:
Missing type enforcement (TE) allow rule.
2) using /var/xguest DID work, despite the warning during the useradd:
libsemanage.get_home_dirs: xguest homedir /var/xguest or its parent directory conflicts with a file context already specified in the policy. This usually indicates an incorrectly defined system account. If it is a system account please make sure its uid is less than 500 or its login shell is /sbin/nologin.
It would be nice if we could decide on a best place for the home directory for xguest (outside of /home, and under /var), fix up the SElinux policy accordingly, and upstream this for future Fedora releases. I'll adjust my RHEL xguest locally to match, but I suppose this wouldn't be suitable for a rhel 6 update?
I agree, I like this idea, but I am trying to figure out the best location Bill what do you think of this? What location? How much is placed in this directory at runtime? I'd be a little leery of putting something that might have heavy storage on tmpfs. That being said, /run/xguest or /run/user/xguest may work. Of course, given that it's RHEL 6 (oops), you'd want /var/run, not /run. And then the tmpfs issues aren't there. (In reply to comment #10) > How much is placed in this directory at runtime? I'd be a little leery of > putting something that might have heavy storage on tmpfs. > Well, it's not actually used to store much data as the real home directory for xguest user is polyinstantiated as tmpfs at login, as I understand it. I could be misunderstanding. > That being said, /run/xguest or /run/user/xguest may work. (In reply to comment #11) > Of course, given that it's RHEL 6 (oops), you'd want /var/run, not /run. And > then the tmpfs issues aren't there. Well, it's unclear if this would be a suitable update for RHEL 6 - it'd be nice if it was. I do wonder if /var/run is not the wrong place though - the /var/run directory is described in the FHS as "contains system information data describing the system since it was booted. Files under this directory must be cleared (removed or truncated as appropriate) at the beginning of the boot process." Are there any implications of the requirement that the directory be cleared at boot? Does the same requirement hold for /run? Maybe I am overanalysing.. OK, having thought about it a bit I plumped with /var/lib/xguest/home. Doing this to create the user: useradd -c "Guest" -Z xguest_u xguest -U -u 500 -m -d /var/lib/xguest/home || semanage login -a -S targeted -s xguest_u xguest || semanage login -m -S targeted -s xguest_u xguest works fine, and the xguest user can log in. But I am a little confused as to the selinux labellig of these directories. After creating the xguest user as above, the labels are: # ls -ldZ /var/lib/xguest/ drwxr-xr-x. root root unconfined_u:object_r:var_lib_t:s0 /var/lib/xguest/ # ls -ldZ /var/lib/xguest/home drwx------. xguest xguest xguest_u:object_r:user_home_dir_t:s0 /var/lib/xguest/home Just to see what breaks, I then did a restorecon -R /var/lib/xguest which relabels the directories as: # ls -ldZ /var/lib/xguest/ drwxr-xr-x. root root system_u:object_r:home_root_t:s0 /var/lib/xguest/ # ls -ldZ /var/lib/xguest/home/ drwx------. xguest xguest xguest_u:object_r:user_home_dir_t:s0 /var/lib/xguest/home/ .. and the guest account still works, which is good news. I'm just not sure if these labels are indeed correct after the restorecon? They are, well somewhat. Currently we expect the parent directory of homedirs to be labeled home_root_t. This allows us to write a transition rule stating any admin creating a directory in a home_root_t, will create the directory labeled user_home_dir_t. The only potential problem I see with placing xguest users homedir in /var/lib, is that if we end up writing a confined app and using it with xguest, the confined app will need to be able to search var_lib_t to get to the homedir. But this does not seem to be that big of a burden. After more thought I agree /var/run or /run is not the correct place for this dir, running out of tmpfs space and other tools allowed to clean up /run could cause problems. I would rather do /var/lib/home/xguest though. (In reply to comment #14) > They are, well somewhat. Currently we expect the parent directory of homedirs > to be labeled home_root_t. This allows us to write a transition rule stating > any admin creating a directory in a home_root_t, will create the directory > labeled user_home_dir_t. > > The only potential problem I see with placing xguest users homedir in /var/lib, > is that if we end up writing a confined app and using it with xguest, the > confined app will need to be able to search var_lib_t to get to the homedir. > But this does not seem to be that big of a burden. > > After more thought I agree /var/run or /run is not the correct place for this > dir, running out of tmpfs space and other tools allowed to clean up /run could > cause problems. > OK, good. > I would rather do /var/lib/home/xguest though. Without wishing to bikeshed, and I can see the appeal of /var/lib/home/xguest as it mirrors /home/xguest, but convention (and also as FHS describes) is that applications should create their own directories under /var/lib named after the application... and since the application is xguest, that gives us /var/lib/xguest. Having a /home under there then seems reasonable, IMO. A directory of /var/lib/home would indicate it's owned by an application called "home" :). Anyway, that was my thinking. This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unfortunately unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux. If you would like it considered as an exception in the current release, please ask your support representative. Red Hat Enterprise Linux version 6 is entering the Production 2 phase of its lifetime and this bug doesn't meet the criteria for it, i.e. only high severity issues will be fixed. Please see https://access.redhat.com/support/policy/updates/errata/ for further information. Feel free to clone this bug to RHEL-7 if it is still a problem for you. |