Re: genhomedircon is broken in libsemanage

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Joshua Brindle wrote:
> Daniel J Walsh wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Joshua Brindle wrote:
>>  
>>> Todd Miller wrote:
>>>    
>>>> Daniel J Walsh wrote:
>>>>  
>>>>      
>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>> Hash: SHA1
>>>>>
>>>>> Adding
>>>>>
>>>>> mythtv:x:1004:1004::/var/lib/mythtv:/bin/bash
>>>>>
>>>>> To /etc/passwd causes the labeling to get all screwed up.  This would
>>>>> report an error when we used the python version of genhomedircon and
>>>>> not foul up the labeling by checking if there was a label for /var/lib
>>>>> already in the file_context file. (Boy do I love python.  :^))
>>>>>
>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=430195
>>>>>
>>>>> Dan
>>>>>             
>>>> That shouldn't be hard to add to genhomedircon.c.  I'll take a look.
>>>>         
>>> So, Todd is about to send a patch to fix this but I want to point out
>>> that I'm adverse to this sort of thing. There is a minuid and a null
>>> shell for a reason, using something above minuid with a valid shell for
>>> a non-interactive user is a broken configuration and the fact that we
>>> have to work around it is pretty unfortunate.
>>>
>>> That said the alternative of breaking the system labeling is pretty bad,
>>> its probably better to hack around the problem than leave clueless users
>>> with broken configurations stranded but I really wish we didn't have to
>>> do things like this.
>>>
>>> *sigh*
>>>
>>>     
>> I think you need to scream in the semanage that this is bad behavior,
>> and you can't fix the labels.  The /var/lib situation is bad, but I more
>> commonly see admins putting real users in /usr/local or under /var.  We
>> need to have a message that explains this is bad and SELinux can not
>> handle it.
>>   
> 
> Well, this is part of the configurability of Linux and thats why people
> love it, right? One solution would be to effectively get rid of
> directory search denials on commodity policies (eg., give all domains
> search on all dirs for the RH policy) then we don't have to worry about
> the "top level home" directory label at all.
> 
It is not that simple. useradd relies on home_root_t to create
directories labeled user_home_dir_t.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkegkMIACgkQrlYvE4MpobOS5QCcDfZxBWa5jVJEgrx+80h68Fuw
ev8An1vnlQ5CYlarth6aUnClkbxS8b/M
=sy3x
-----END PGP SIGNATURE-----

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with
the words "unsubscribe selinux" without quotes as the message.

[Index of Archives]     [Selinux Refpolicy]     [Linux SGX]     [Fedora Users]     [Fedora Desktop]     [Yosemite Photos]     [Yosemite Camping]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux