Hi Christian,
thanks again for your very valuable help. It's much appreciated!
Am 28.06.2015 um 20:30 schrieb Christian Seiler:
> On 06/28/2015 08:03 PM, Christian Seiler wrote:
>> On 06/28/2015 07:51 PM, Jonas Meurer wrote:
>>> root@clt# su -s /bin/sh -c "cat /var/vmail/test.txt" mail
>>> test
>>> root@clt# su -s /bin/sh -c "touch /var/vmail/test" mail
>>> touch: cannot touch ‘/var/vmail/test’: Permission denied
>>>
>>> The Kerberos ticket for local user 'mail' is managed by k5start:
>>>
>>> clt# ps -ef |grep k5start | grep mail
>>> root 8965 1 0 16:04 ? 00:00:00 /usr/bin/k5start -u \
>>> mail/nfs-client -o mail -p /var/run/k5start-mail.pid -b \
>>> -f /etc/krb5.keytab -L -K 30
>>>
>>> I don't understand why I don't have write access to the share as client
>>> user 'mail' (authenticated to Kerberos server as 'mail/nfs-client'.
>>
>> What ticket cache is k5start using? Does the user k5mail have
>> access to it and does it know about it after su?
>>
>> What do the following commands say?
>>
>> su -s /bin/sh -c "echo $KRB5CCNAME" mail
>> su -s /bin/sh -c "klist" mail
>>
>> It appears to me that you are running k5start as root and it uses
>> the root user's default ticket cache - which as a) not known and
>> b) not accessible to the mail user.
>>
>> You will probably want to specify the -k /path/to/cache and -o mail
>> options to k5start - and you probably want to explicitly set
>> KRB5CCNAME=FILE:/path/to/cache before running anything as the user
>> mail.
Indeed, this was the problem. All instances of k5start used the default
ticket cache which seems to be /tmp/krb5cc_0 (0 for UID '0'). A quick
test reveiled that kerberos defaults to '/tmp/krb5cc_<UID>' for the
ticket cache. I now changed my k5start init script to set the ticket
cache accordingly, and afterwards that works:
clt# ps -ef | grep k5start | grep mail
root 10149 1 0 20:56 ? 00:00:00 /usr/bin/k5start -u mail \
-o mail -p /var/run/k5start-mail.pid -k /tmp/krb5cc_8 \
-b -f /etc/krb5.keytab -L -K 30
clt# su -s /bin/sh -c "echo $KRB5CCNAME" mail
clt# su -s /bin/sh -c "klist" mail
Ticket cache: FILE:/tmp/krb5cc_8
Default principal: mail@REALM
Valid starting Expires Service principal
06/28/2015 20:56:13 06/29/2015 06:56:13 krbtgt/REALM@REALM
> Also, I just noticed that your principal name was mail/nfs-client.
> Did you set up idmapping on the server correctly for that to work?
Yes, I fiddled around with static mapping. But now that I read your
explanation, using usernames without hostname as principal name sounds
way more obvious. As you can see above, I changed this now.
> Because if you use nsswitch idmapping (i.e. using the same as libc
> to resolve uids/gids, also the default), that will never work;
> nsswitch idmapping will always just accept username@REALM as the
> principal.
>
> So you should either tell it to fetch the principal 'mail' or, if
> you insist on keeping mail/nfs-client, then you should do:
>
> - if you are using umich_ldap, you can additionally have the
> GSSAuthName LDAP attribute and set that to mail/nfs-client
> for the 'mail' user
I don't use LDAP at all.
> - or, you can also add a static mapping for just the mail user,
> mail/nfs-client, by editing the idmapd.conf on the server,
> where you should then set
>
> [Translation]
> GSS-Methods=static,VALUE_WHAT_IT_WAS_BEFORE
> [Static]
> mail/nfs-client@REALM = mail
>
> (If no GSS-Methods were specified, copy the contents of
> the Methods= settings to VALUE_WHAT_IT_WAS_BEFORE.)
That's exactly, what I did before. I removed the static mapping (except
for user root) now that I migrated to your simpler approach.
Now - after a reboot that cleared all krb5 tickets and caches - write
access to the NFS shares works as normal user when the user has been
authenticated to the Kerberos server (via k5start) first.
Thank you very much, that was a big step forward for my new setup!
Cheers,
jonas
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/559067a2.4050...@freesources.org
