procmail with nfs home dirs

[Matthew Gillen]

Daniel J Walsh wrote:
> Paul Howarth wrote:
>> On Thu, 2006-09-07 at 19:38 -0400, Matthew Gillen wrote:
>>  
>>> Daniel J Walsh wrote:
>>>    
>>>> Matthew Gillen wrote:
>>>>      
>>>>> Hi,
>>>>> I'm new to SELinux, and I was having some problems with procmail not
>>>>> working
>>>>> correctly for me with NFS (via NIS-based autofs) home directories
>>>>> on FC5.
>>>>>
>>>>> There seemed to be a discussion about a similar issue a while back:
>>>>> http://www.redhat.com/archives/fedora-list/2006-May/msg03265.html
>>>>> but the solutions there didn't solve my problem.
>>>>>
>>>>> In any event, I managed to get it working for myself using the
>>>>> following
>>>>> policy module.  The 'autofs_t:dir search' part seemed to be needed to
>>>>> find
>>>>> my .procmailrc file, and the rest looks like it is needed to write
>>>>> messages
>>>>> into my maildirs under $HOME/Mail/
>>>>>
>>>>> If anyone has suggestions on how to improve this I'd be happy to hear
>>>>> them.
>>>>> Thanks,
>>>>> Matt
>>>>>
>>>>> --------------------------------------
>>>>> module procmailnfs 1.0;
>>>>>
>>>>> require {
>>>>>         class dir { getattr search write };
>>>>>         class file { append getattr read };
>>>>>         type autofs_t;
>>>>>         type default_t;
>>>>>         type procmail_t;
>>>>>         role system_r;
>>>>> };
>>>>>
>>>>> allow procmail_t autofs_t:dir search;
>>>>> allow procmail_t default_t:dir { getattr search write };
>>>>> allow procmail_t default_t:file { append getattr read };
>>>>> --------------------------------------
>>>>>
>>>>>           
>>>> This looks like a labeling problem.  What directory is labeled
>>>> default_t?
>>>>       
>>> I think I need to explain a bit more about my setup. Basically, I've 
>>> got one machine that's an NIS+NFS server and a mail server. This
>>> machine has /export/home set up as one of it's nfs shares.
>>> After a '/sbin/restorecon -v -R /export/home', the ls -Z output for
>>> /export/home/username is system_u:object_r:default_t.
>>>
>>> Here's where it gets interesting. The NFS server will automount from 
>>> itself for users in NIS. If I log into the NFS server as 'username',
>>> and do 'ls -lZd /home/username', the result is
>>> 'system_u:object_r:default_t'. However, if I'm on some other machine
>>> (that is an NFS client), the 'ls -Z' output for /home/username is
>>> 'system_u:object_r:nfs_t'
>>> On both machines, (the NFS server+client and the pure client) the ls -Z
>>> output for /home indicates 'system_u:object_r:autofs_t'
>>>
>>> So, maybe what's ultimately going on is that there's a bug in setting
>>> the
>>> context for a locally-served NFS share?
>>>     
>>
>> I think it's much simpler than that; there is no default context
>> for /export/home (Fedora home directories default to /home rather
>> than /export/home) and that's why restorecon didn't change anything.
>>
>> Are the home directories in the NIS database listed as being in /home
>> or /export/home?

'getent passwd' would say that the home dirs are in /home.  And
/etc/auto.home on the server contains:
# Auto.home
*       server:/export/home/&

So, I think the answer to your question is /home.  I did just notice
something peculiar though: on the server, the automounted entries (/home/*)
don't show up when I run 'df'.  On a pure client, 'df' reports all the
automounted home dirs:
Filesystem				Mounted On
server:/export/home/user1	...	/home/user1
server:/export/home/user2	...	/home/user2

> Yes the question is where are the homedirs comeing from an what are they
> labeled?  Are you doing a bind mount on the local machine.

I'm not sure what you mean by a 'bind mount'.

> Try
> chcon -t home_root_t /export/home

Ok, I did that, but what should I expect to change (other than the output of
'ls -Zd /export/home') ?  Should that change the behavior of restorecon for
/export/home/* ?

Thanks,
Matt