[Freeipa-users] Mount cifs share using kerberos

[Alexander Bokovoy]

On Wed, 14 Jan 2015, John Obaterspok wrote:
>2015-01-12 10:13 GMT+01:00 Alexander Bokovoy <abokovoy at redhat.com>:
>
>> On Mon, 12 Jan 2015, John Obaterspok wrote:
>>
>>> 2015-01-11 16:33 GMT+01:00 Jakub Hrozek <jhrozek at redhat.com>:
>>>
>>>  On Sun, Jan 11, 2015 at 11:00:16AM +0100, John Obaterspok wrote:
>>>> > 2015-01-10 13:32 GMT+01:00 Gianluca Cecchi <gianluca.cecchi at gmail.com
>>>> >:
>>>> >
>>>> > > To get the whole root environment you have to run
>>>> > > su - root
>>>> > > did you try with it?
>>>> > >
>>>> >
>>>> > ahh... that works fine Gianluca!
>>>> >
>>>> > Final question, if I have a file on the share like:
>>>> >      [john at ipaserver mountpoint]$ ll test.txt
>>>> >      -rwxr-----. 1 root admins 12 11 jan 10.42 test.txt
>>>> >
>>>> > Should I be able to access it if I aquire an admin ticket? Currently I
>>>> get
>>>> > Permission denied
>>>> >
>>>> > [john at ipaserver mountpoint]$ id
>>>> > uid=1434400004(john) gid=1434400004(john) grupper=1434400004(john)
>>>> > context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
>>>> >
>>>> > [john at ipaserver mountpoint]$ getfacl test.txt
>>>> > # file: test.txt
>>>> > # owner: root
>>>> > # group: admins
>>>> > user::rwx
>>>> > group::r--
>>>> > other::---
>>>> >
>>>> > [john at ipaserver mountpoint]$ id admin
>>>> > uid=1434400000(admin) gid=1434400000(admins) groups=1434400000(admins)
>>>> >
>>>> > [john at ipaserver mountpoint]$ klist
>>>> > Ticket cache: KEYRING:persistent:1434400004:krb_ccache_MVjxTqf
>>>> > Default principal: admin at MY.LAN
>>>> >
>>>> > Valid starting       Expires              Service principal
>>>> > 2015-01-11 10:43:52  2015-01-12 10:43:50  krbtgt/MY.LAN at MY.LAN
>>>> >
>>>> > [john at ipaserver mountpoint]$ cat test.txt
>>>> > cat: test.txt: Permission denied
>>>>
>>>> Looks like your account needs to be in the 'admins' group in order to
>>>> access the file.
>>>>
>>>> Acquiring the admin ticket doesn't switch the user ID nor add you to the
>>>> group..
>>>>
>>>>
>>>>  I thought the krb5 mount option would allow ticked based access to the
>>> file.
>>> Is the purpose of the krb5 mount option just used during mounting of the
>>> share? Otherwise I see no difference compared to not using krb5 mount
>>> option!?
>>>
>> Its purpose is authentication. After you have been successfully
>> recognized by the server, both client and server need to map your
>> identity while authorizing your access to actual files.
>>
>> In CIFS there are two types of access control which are applied at the
>> same time:
>> - ACLs per file or directory
>> - POSIX access control based on uid/gid of a process that accesses the
>>   file or directory
>>
>> Client-side checks in cifs.ko can be switched off by noperm option. In
>> this case server side will be doing actual access enforcement, using the
>> uid/gid mapped on the server side (based on the Kerberos principal),
>> unless CIFS Unix Extensions were negotiated between cifs.ko and the
>> server. In the latter case client will pass uid/gid of a client to the
>> server and server will do the actual check using them instead of
>> discovering them based on the authentication token.
>>
>> In case where there is a common identity store in use with Kerberos, it
>> is often better to use cifs.ko option multiuser which will imply noperm
>> and server will be doing all the checks.
>
>
>Simo also added that "You need to pass the 'multiuser' option at mount time
>for that, the
>default for cifs.ko is still to just use the mount credentials."
>
>Well, I were actually using multiuser in the original test where I got
>"permission denied" but there is something weird going on.
Nothing weird (tl;dr).

>mount -t cifs //ipaserver.MY.LAN/Share -o sec=krb5,multiuser mountpoint (I
>also tried -o sec=krb5,multiuser,cache=none)
>
>Anyway, it works if I do the mount as root and then as user john gets the
>admin ticket *before* going to the share. Then it doesn't matter if I do
>kdestroy, I can still access a file that would require admin ticket.
>If I remount the share and go to share as john without admin ticket I can't
>access a file that would require admin ticket. If I get an admin ticket
>then I'm still not able to access the file.
Kerberos authentication happens when you first access the share as a new
user -- cifs.ko will ask userspace to provide Kerberos credentials to
the kernel so that negotiation can happen. Once it is done, the
credentials are valid until the actual Kerberos ticket expires or until
session expires.

So when you access file as john while having admin ticket, you get admin
ticket used for multiuser access. Destroying ccache does not affect
already performed negotiation.

When you remount, previous credentials that cifs.ko used are cleaned,
thus cannot be used. If you try to access the mount point as 'john'
without Kerberos credentials, you'd be negotiating anonymous connection
which would only succeed if the share is allowed to connect to
anonymously (guest ok = yes).

However, you accessed the share with john Kerberos credentials. These
credentials were negotiated and will be valid until the connection is
dropped or ticket expires, whichever event comes first. In fact, cifs.ko
expires sessions periodically but I was unable to find exact expiration
time myself.

-- 
/ Alexander Bokovoy