procmail with nfs home dirs
Matthew Gillen
matt at gillens.us
Sat Sep 9 02:11:47 UTC 2006
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
More information about the fedora-selinux-list
mailing list