On Mon, 12 Jan 2015, John Obaterspok wrote:
2015-01-11 16:33 GMT+01:00 Jakub Hrozek <jhro...@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.cec...@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@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@ipaserver mountpoint]$ id
> uid=1434400004(john) gid=1434400004(john) grupper=1434400004(john)
> context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
>
> [john@ipaserver mountpoint]$ getfacl test.txt
> # file: test.txt
> # owner: root
> # group: admins
> user::rwx
> group::r--
> other::---
>
> [john@ipaserver mountpoint]$ id admin
> uid=1434400000(admin) gid=1434400000(admins) groups=1434400000(admins)
>
> [john@ipaserver mountpoint]$ klist
> Ticket cache: KEYRING:persistent:1434400004:krb_ccache_MVjxTqf
> Default principal: ad...@my.lan
>
> Valid starting       Expires              Service principal
> 2015-01-11 10:43:52  2015-01-12 10:43:50  krbtgt/my....@my.lan
>
> [john@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

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project

Reply via email to