[Freeipa-users] Mount cifs share using kerberos

[Alexander Bokovoy]

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.

-- 
/ Alexander Bokovoy