* no_root_squash (and valid KRB root-ticket) @ 2010-11-16 14:27 Valentijn Sessink 2010-11-16 18:30 ` J. Bruce Fields 2010-11-17 10:51 ` Valentijn Sessink 0 siblings, 2 replies; 11+ messages in thread From: Valentijn Sessink @ 2010-11-16 14:27 UTC (permalink / raw) To: linux-nfs 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: no_root_squash (and valid KRB root-ticket) 2010-11-16 14:27 no_root_squash (and valid KRB root-ticket) Valentijn Sessink @ 2010-11-16 18:30 ` J. Bruce Fields 2010-11-16 19:52 ` Valentijn Sessink 2010-11-17 10:51 ` Valentijn Sessink 1 sibling, 1 reply; 11+ messages in thread From: J. Bruce Fields @ 2010-11-16 18:30 UTC (permalink / raw) To: Valentijn Sessink; +Cc: linux-nfs 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: no_root_squash (and valid KRB root-ticket) 2010-11-16 18:30 ` J. Bruce Fields @ 2010-11-16 19:52 ` Valentijn Sessink 2010-11-16 23:54 ` Kevin Coffman 0 siblings, 1 reply; 11+ messages in thread From: Valentijn Sessink @ 2010-11-16 19:52 UTC (permalink / raw) To: J. Bruce Fields; +Cc: linux-nfs 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: no_root_squash (and valid KRB root-ticket) 2010-11-16 19:52 ` Valentijn Sessink @ 2010-11-16 23:54 ` Kevin Coffman 0 siblings, 0 replies; 11+ messages in thread From: Kevin Coffman @ 2010-11-16 23:54 UTC (permalink / raw) To: Valentijn Sessink; +Cc: J. Bruce Fields, linux-nfs 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 > > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: no_root_squash (and valid KRB root-ticket) 2010-11-16 14:27 no_root_squash (and valid KRB root-ticket) Valentijn Sessink 2010-11-16 18:30 ` J. Bruce Fields @ 2010-11-17 10:51 ` Valentijn Sessink 2010-11-17 14:26 ` Kevin Coffman 1 sibling, 1 reply; 11+ messages in thread From: Valentijn Sessink @ 2010-11-17 10:51 UTC (permalink / raw) To: linux-nfs 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: no_root_squash (and valid KRB root-ticket) 2010-11-17 10:51 ` Valentijn Sessink @ 2010-11-17 14:26 ` Kevin Coffman 2010-11-18 9:59 ` Valentijn Sessink 0 siblings, 1 reply; 11+ messages in thread From: Kevin Coffman @ 2010-11-17 14:26 UTC (permalink / raw) To: Valentijn Sessink; +Cc: linux-nfs 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: no_root_squash (and valid KRB root-ticket) 2010-11-17 14:26 ` Kevin Coffman @ 2010-11-18 9:59 ` Valentijn Sessink 2010-11-18 14:25 ` Kevin Coffman 0 siblings, 1 reply; 11+ messages in thread From: Valentijn Sessink @ 2010-11-18 9:59 UTC (permalink / raw) To: Kevin Coffman; +Cc: linux-nfs 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: no_root_squash (and valid KRB root-ticket) 2010-11-18 9:59 ` Valentijn Sessink @ 2010-11-18 14:25 ` Kevin Coffman 2010-11-18 15:07 ` Valentijn Sessink 0 siblings, 1 reply; 11+ messages in thread From: Kevin Coffman @ 2010-11-18 14:25 UTC (permalink / raw) To: Valentijn Sessink; +Cc: linux-nfs 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: no_root_squash (and valid KRB root-ticket) 2010-11-18 14:25 ` Kevin Coffman @ 2010-11-18 15:07 ` Valentijn Sessink 2010-11-18 15:27 ` Kevin Coffman 0 siblings, 1 reply; 11+ messages in thread From: Valentijn Sessink @ 2010-11-18 15:07 UTC (permalink / raw) To: Kevin Coffman; +Cc: linux-nfs 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: no_root_squash (and valid KRB root-ticket) 2010-11-18 15:07 ` Valentijn Sessink @ 2010-11-18 15:27 ` Kevin Coffman 2010-11-18 17:46 ` J. Bruce Fields 0 siblings, 1 reply; 11+ messages in thread From: Kevin Coffman @ 2010-11-18 15:27 UTC (permalink / raw) To: Valentijn Sessink; +Cc: linux-nfs 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: no_root_squash (and valid KRB root-ticket) 2010-11-18 15:27 ` Kevin Coffman @ 2010-11-18 17:46 ` J. Bruce Fields 0 siblings, 0 replies; 11+ messages in thread From: J. Bruce Fields @ 2010-11-18 17:46 UTC (permalink / raw) To: Kevin Coffman; +Cc: Valentijn Sessink, linux-nfs 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2010-11-18 17:46 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2010-11-16 14:27 no_root_squash (and valid KRB root-ticket) Valentijn Sessink 2010-11-16 18:30 ` J. Bruce Fields 2010-11-16 19:52 ` Valentijn Sessink 2010-11-16 23:54 ` Kevin Coffman 2010-11-17 10:51 ` Valentijn Sessink 2010-11-17 14:26 ` Kevin Coffman 2010-11-18 9:59 ` Valentijn Sessink 2010-11-18 14:25 ` Kevin Coffman 2010-11-18 15:07 ` Valentijn Sessink 2010-11-18 15:27 ` Kevin Coffman 2010-11-18 17:46 ` J. Bruce Fields
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.