On Wed, 14 Jan 2015, John Obaterspok wrote:
2015-01-12 10:13 GMT+01:00 Alexander Bokovoy <aboko...@redhat.com>:
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.
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
--
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
