no_root_squash (and valid KRB root-ticket)

no_root_squash (and valid KRB root-ticket)

[Valentijn Sessink]

Hello list,

I found that having "no_root_squash" on the server, having a valid
Kerberos ticket for root@DOMAIN, does still not give you root rights on
a share. Looking further, I found
http://www.unix-info.org/nfsV4_howto_.txt that says that there is "no
proper mapping between root and the GSSAuthName"; but I could not find
the status of this document.

Could any of you comment on this? Is this still the case (I suppose so)?

Best regards,

Valentijn

Re: no_root_squash (and valid KRB root-ticket)

[J. Bruce Fields]

On Tue, Nov 16, 2010 at 03:27:41PM +0100, Valentijn Sessink wrote:
> Hello list,
> 
> I found that having "no_root_squash" on the server, having a valid
> Kerberos ticket for root@DOMAIN, does still not give you root rights on
> a share. Looking further, I found
> http://www.unix-info.org/nfsV4_howto_.txt that says that there is "no
> proper mapping between root and the GSSAuthName"; but I could not find
> the status of this document.
> 
> Could any of you comment on this? Is this still the case (I suppose so)?

This is between a linux client and server?

Are other kerberos principals mapped as you'd expect?

I don't recall the code treating root specially, but I haven't checked.

--b.

Re: no_root_squash (and valid KRB root-ticket)

[Valentijn Sessink]

Hi,

Op 16-11-10 19:30, J. Bruce Fields schreef:
>> I found that having "no_root_squash" on the server, having a valid
>> Kerberos ticket for root@DOMAIN, does still not give you root rights on
>> a share.
> This is between a linux client and server?

Yes. Not a really recent one though, must be Ubuntu 10.04 server and client.

> Are other kerberos principals mapped as you'd expect?

Yes — it's on our production network, user ID's are mapped without a 
problem. While I'm typing this: I did not check what idmapd says; most 
of the users are in LDAP, while root is just a local user with a 
corresponding local user on the server. Can't think of a reason why this 
should bar root from using the share, but I will check that, tomorrow, 
just to be sure.

V.

Re: no_root_squash (and valid KRB root-ticket)

[Kevin Coffman]

I believe the answer is to add a "static" mapping of some principal
name to be "root" locally on the server machine.

See the example in the idmap.conf man page (that comes with libnfsidmap).



On Tue, Nov 16, 2010 at 2:52 PM, Valentijn Sessink <valentyn@blub.net> wrote:
> Hi,
>
> Op 16-11-10 19:30, J. Bruce Fields schreef:
>>>
>>> I found that having "no_root_squash" on the server, having a valid
>>> Kerberos ticket for root@DOMAIN, does still not give you root rights on
>>> a share.
>>
>> This is between a linux client and server?
>
> Yes. Not a really recent one though, must be Ubuntu 10.04 server and client.
>
>> Are other kerberos principals mapped as you'd expect?
>
> Yes — it's on our production network, user ID's are mapped without a
> problem. While I'm typing this: I did not check what idmapd says; most of
> the users are in LDAP, while root is just a local user with a corresponding
> local user on the server. Can't think of a reason why this should bar root
> from using the share, but I will check that, tomorrow, just to be sure.
>
> V.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>

Re: no_root_squash (and valid KRB root-ticket)

[Valentijn Sessink]

Valentijn Sessink schreef:
> http://www.unix-info.org/nfsV4_howto_.txt that says that there is "no
> proper mapping between root and the GSSAuthName";

The gssd man page says:

``By default, rpc.gssd treats accesses by the user with UID 0 specially,
 and uses "machine credentials" for all accesses by that
user which require Kerberos authentication.  With the -n option,
"machine  credentials"  will  not be used for accesses by UID 0.
Instead, credentials must be obtained manually  like  all  other users.
  Use  of  this  option  means  that "root" must manually obtain
Kerberos credentials before attempting to  mount  an  nfs filesystem
requiring Kerberos authentication.''

That - sort of - answers the question: I'm being held for a machine.

A bit odd is, that I can be root on the share by using root's
credentials from within another UID (because technically, your Kerberos
login is just a way to map your local user ID to the server's user ID):

root@host32:~# su - adam
No directory, logging in with HOME=/
adam@host32:/$ kinit root
root@KERBEROS.DOMAIN's Password:
adam@host32:/$ cd /home/
adam@host32:/home$ touch file
adam@host32:/home$ ls -al file
-rw-rw-r--  1 root root    0 2010-11-17 11:28 file

On the server, "file" is also owned by root:root. So you can be root,
but not as root. (And if "adam" logs in to host32 shortly after our
excercise, he will be pleasantly surprised to see that he owns
everything on /home - although this will turn out to be a sort of King
Midas' touch, because on next login, the cached UID mapping will long be
forgotten and he won't be able to access all those documents owned by
root...)

Final question: having seen the gssd page, I don't think there's a way
for "root" on the local machine to have root rights on the server, or is
there? (Having to get manual kerberos credentials to mount /home, with
the "-n" switch, is not an option).

Valentijn
-- 
http://www.openoffice.nl/   Open Office - Linux Office Solutions
Valentijn Sessink  v.sessink@openoffice.nl  +31(0)20-4214059

Re: no_root_squash (and valid KRB root-ticket)

[Kevin Coffman]

On Wed, Nov 17, 2010 at 5:51 AM, Valentijn Sessink
<v.sessink@openoffice.nl> wrote:
> Valentijn Sessink schreef:
>> http://www.unix-info.org/nfsV4_howto_.txt that says that there is "no
>> proper mapping between root and the GSSAuthName";
>
> The gssd man page says:
>
> ``By default, rpc.gssd treats accesses by the user with UID 0 specially,
>  and uses "machine credentials" for all accesses by that
> user which require Kerberos authentication.  With the -n option,
> "machine  credentials"  will  not be used for accesses by UID 0.
> Instead, credentials must be obtained manually  like  all  other users.
>  Use  of  this  option  means  that "root" must manually obtain
> Kerberos credentials before attempting to  mount  an  nfs filesystem
> requiring Kerberos authentication.''
>
> That - sort of - answers the question: I'm being held for a machine.
>
> A bit odd is, that I can be root on the share by using root's
> credentials from within another UID (because technically, your Kerberos
> login is just a way to map your local user ID to the server's user ID):
>
> root@host32:~# su - adam
> No directory, logging in with HOME=/
> adam@host32:/$ kinit root
> root@KERBEROS.DOMAIN's Password:
> adam@host32:/$ cd /home/
> adam@host32:/home$ touch file
> adam@host32:/home$ ls -al file
> -rw-rw-r--  1 root root    0 2010-11-17 11:28 file
>
> On the server, "file" is also owned by root:root. So you can be root,
> but not as root. (And if "adam" logs in to host32 shortly after our
> excercise, he will be pleasantly surprised to see that he owns
> everything on /home - although this will turn out to be a sort of King
> Midas' touch, because on next login, the cached UID mapping will long be
> forgotten and he won't be able to access all those documents owned by
> root...)
>
> Final question: having seen the gssd page, I don't think there's a way
> for "root" on the local machine to have root rights on the server, or is
> there? (Having to get manual kerberos credentials to mount /home, with
> the "-n" switch, is not an option).

Did you see my message about "static" mapping for libnfsidmap?

On your server, you can map "host/client.machine@REALM" to root.  (Or
"nfs/client.machine@REALM" or "root/client.machine@REALM", depending
on what key you have on the client.)

K.C.

Re: no_root_squash (and valid KRB root-ticket)

[Valentijn Sessink]

Kevin Coffman schreef:
> Did you see my message about "static" mapping for libnfsidmap?

Yes, but it's scope was not immediately clear to me. Also, I couldn't
find the mapping feature you were mentioning; but my idmapd man page
comes from the nfs-common sources, while your idmapd.conf example (as
you explained) comes from libnfsidmap.

> On your server, you can map "host/client.machine@REALM" to root.  (Or
> "nfs/client.machine@REALM" or "root/client.machine@REALM", depending
> on what key you have on the client.)

OK, now I understand :) As far as I can see, that would mean that anyone
with root rights on the client (thus being able to read the machine
keys) would have root rights on the server share, wouldn't it?

Best regards,

Valentijn

Re: no_root_squash (and valid KRB root-ticket)

[Kevin Coffman]

On Thu, Nov 18, 2010 at 4:59 AM, Valentijn Sessink <valentyn@blub.net> wrote:
> Kevin Coffman schreef:
>> Did you see my message about "static" mapping for libnfsidmap?
>
> Yes, but it's scope was not immediately clear to me. Also, I couldn't
> find the mapping feature you were mentioning; but my idmapd man page
> comes from the nfs-common sources, while your idmapd.conf example (as
> you explained) comes from libnfsidmap.
>
>> On your server, you can map "host/client.machine@REALM" to root.  (Or
>> "nfs/client.machine@REALM" or "root/client.machine@REALM", depending
>> on what key you have on the client.)
>
> OK, now I understand :) As far as I can see, that would mean that anyone
> with root rights on the client (thus being able to read the machine
> keys) would have root rights on the server share, wouldn't it?

Isn't that the equivalent of no_root_squash?  (root on the client ==
root on the server)

You are free to map any principal to root on the server.  It doesn't
have to be a client's machine credentials.

K.C.

Re: no_root_squash (and valid KRB root-ticket)

[Valentijn Sessink]

Hi Kevin,

Kevin Coffman schreef:
>>> On your server, you can map "host/client.machine@REALM" to root.  (Or
>>> "nfs/client.machine@REALM" or "root/client.machine@REALM", depending
>>> on what key you have on the client.)
>> As far as I can see, that would mean that anyone
>> with root rights on the client (thus being able to read the machine
>> keys) would have root rights on the server share, wouldn't it?
> Isn't that the equivalent of no_root_squash?  (root on the client ==
> root on the server)

It used to be, when local UID = server UID was the fine way of
authenticating - but with KRB authentication, the idea is that you
authenticate to the server.

To summarize: when your UID=0 on the client, you cannot be root at the
server, because UID=0 is handled differently by gssd. If you have any
other UID, you can map this to UID=0 on the server - either by using
"kinit root" at the client, or by setting up a specific mapping for
libnfsidmap.

Thanks for you help.

Best regards,

Valentijn

Re: no_root_squash (and valid KRB root-ticket)

[Kevin Coffman]

On Thu, Nov 18, 2010 at 10:07 AM, Valentijn Sessink <valentyn@blub.net> wrote:
> Hi Kevin,
>
> Kevin Coffman schreef:
>>>> On your server, you can map "host/client.machine@REALM" to root.  (Or
>>>> "nfs/client.machine@REALM" or "root/client.machine@REALM", depending
>>>> on what key you have on the client.)
>>> As far as I can see, that would mean that anyone
>>> with root rights on the client (thus being able to read the machine
>>> keys) would have root rights on the server share, wouldn't it?
>> Isn't that the equivalent of no_root_squash?  (root on the client ==
>> root on the server)
>
> It used to be, when local UID = server UID was the fine way of
> authenticating - but with KRB authentication, the idea is that you
> authenticate to the server.
>
> To summarize: when your UID=0 on the client, you cannot be root at the
> server, because UID=0 is handled differently by gssd.

Actually, in the case of UID=0, the client's machine credentials are
used.  You can map that Kerberos principal to root on the server.  So
this _is_ possible.

> If you have any
> other UID, you can map this to UID=0 on the server - either by using
> "kinit root" at the client, or by setting up a specific mapping for
> libnfsidmap.

Creating a "root" Kerberos principal is discouraged.  (You might,
however, have a "root/<fqdn>" principal -- that you could use for
machine credentials.)

K.C.

Re: no_root_squash (and valid KRB root-ticket)

[J. Bruce Fields]

On Thu, Nov 18, 2010 at 10:27:02AM -0500, Kevin Coffman wrote:
> On Thu, Nov 18, 2010 at 10:07 AM, Valentijn Sessink <valentyn@blub.net> wrote:
> > Hi Kevin,
> >
> > Kevin Coffman schreef:
> >>>> On your server, you can map "host/client.machine@REALM" to root.  (Or
> >>>> "nfs/client.machine@REALM" or "root/client.machine@REALM", depending
> >>>> on what key you have on the client.)
> >>> As far as I can see, that would mean that anyone
> >>> with root rights on the client (thus being able to read the machine
> >>> keys) would have root rights on the server share, wouldn't it?
> >> Isn't that the equivalent of no_root_squash?  (root on the client ==
> >> root on the server)
> >
> > It used to be, when local UID = server UID was the fine way of
> > authenticating - but with KRB authentication, the idea is that you
> > authenticate to the server.
> >
> > To summarize: when your UID=0 on the client, you cannot be root at the
> > server, because UID=0 is handled differently by gssd.
> 
> Actually, in the case of UID=0, the client's machine credentials are
> used.  You can map that Kerberos principal to root on the server.  So
> this _is_ possible.

Also, the kernel and the gssd upcall should distinguish between
"machine" and "root" now.  I don't know if gssd's using that
information.

--b.

> 
> > If you have any
> > other UID, you can map this to UID=0 on the server - either by using
> > "kinit root" at the client, or by setting up a specific mapping for
> > libnfsidmap.
> 
> Creating a "root" Kerberos principal is discouraged.  (You might,
> however, have a "root/<fqdn>" principal -- that you could use for
> machine credentials.)
> 
> K.C.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html