I'm trying to set up a kerberized NFSv4 client to mount a share using a local
ticket (obtained by PAM when the user logged into the shell) instead of a
machine specific ticket (i.e. I'd like to do user-based authorization). I
already managed to get machine based authentification/authorization working for
a test but i can't (and i don't want to) use local keytab files for storing the
machine keys on the client machines in my production environment.
I'm running the rpc.gssd with the "-n -vvv -rrr" to make it consider user
tickets too.
Now, when I try to mount the share to "/mnt/net" (the according fstab-line
looks like "dnsdhcp:/ /mnt/net nfs4 sec=krb5p,user 0 0") the credentials
cache of the user which is doing the mount is not being used. The second
log message reads
"rpc.gssd[888]: getting credentials for client with uid 0 for server <srvname>"
Googling around a bit i found out that some other people managed to make mount
use the uid of the initiating user rather than 'root'(uid=0) (though they seem
to have other problems...).
I'm not quite sure what is wrong with my setup and therefore i tried to dig
into the code of gssd. The only thing i found is that the uid (0 in my case)
is read from a file "clntXX/krb5" (within a pipefs) which is obviously
written by the kernel.
A kernel update to 2.6.32-19 (i'm using ubuntu karmic on an amd64 machine)
didn't make it any better.
Complete Log (client): http://pastebin.com/s7B2W7ie
The user ticket (i'm running the mount-command from an account of a user which
is authenticated via kerberos (MIT Kerberos5)) resided in
/tmp/krb5cc_10002_H6OYu0
Here's what klist said http://pastebin.com/Lrrs3AwM
And this is the client's krb5.conf: http://pastebin.com/JChsVNJQ
I'm really desperate now because i've been working on this problem for nearly
two weeks now and i couldn't get by...
Can you suggest me how to specify which user should be utilized to carry out
the mount? (Did I misconfigure something?)
By the way i've already downloaded the source-code of the nfs-utils
(ver. 1.2.0) and modified
void handle_krb5_upcall(struct clnt_info *clp)
from
gssd/gssd_proc.c
to statically set uid to 10002 (just for testing what will happen) and it's
pretty interesting what comes out:
http://pastebin.com/Qi1rWMLC
Thanks in advance!
On Wed, Apr 7, 2010 at 7:11 PM, <[email protected]> wrote:
>> By the looks of your /etc/fstab entry, the system (root) will try to
>> mount /mnt/net automatically. ?You could try adding the "noauto"
>> option and then manually issuing the mount command as the user. ?(Or
>> use automount?)
>> K.C.
> I'm pretty sure that it doesn't try to automatically mount the share on
> startup since there is no log entry that would indicate such an attempt.
> I already tried to do the mount as a user (which is authenticated via kerberos
> such that there is a valid ticket for that user) the logs (that i have posted)
> are showing what comes out of it. If I try to do the mount without the fstab-
> entry (i.e. mount -t nfs4 -o sec=krb5p dnsdhcp:/ /mnt/net) it is being
> rejected on the grounds that only root can perform a mount. 'sudo' doesn't
> work currently (i've got some problems with my PAM config for sudo) so I
> haven't had any chance to try it out...
>
> I've already set up automount but it actually does exactly the same as if I
> ran mount manually as described above.
>
> I'm totally confused because I don't understand what people like
> http://thread.gmane.org/gmane.linux.nfsv4/5893
> might have done to perform a mount with normal user privileges. If it was
> really mandatory to be root (as stated by Andy Adamson in the other message)
> then I wouldn't really understand why they should have implemented the uid
> passing using that pipefs file....
Hello Tom,
To allow non-root users to do the mount, add the "user" option to the
entry in /etc/fstab. Then the user with uid 10002 should be able to
kinit and then mount. (Note that in this case, there is no need for
the "-n" option to rpc.gssd.)
K.C.
On Wed, Apr 7, 2010 at 10:37 AM, Tom <[email protected]> wrote:
> I'm trying to set up a kerberized NFSv4 client to mount a share using a local
> ticket (obtained by PAM when the user logged into the shell) instead of a
> machine specific ticket (i.e. I'd like to do user-based authorization). I
> already managed to get machine based authentification/authorization working for
> a test but i can't (and i don't want to) use local keytab files for storing the
> machine keys on the client machines in my production environment.
>
> I'm running the rpc.gssd with the "-n -vvv -rrr" to make it consider user
> tickets too.
> Now, when I try to mount the share to "/mnt/net" (the according fstab-line
> looks like "dnsdhcp:/ /mnt/net ?nfs4 ?sec=krb5p,user 0 0") the credentials
> cache of the user which is doing the mount is not being used. The second
> log message ?reads
> "rpc.gssd[888]: getting credentials for client with uid 0 for server <srvname>"
> Googling around a bit i found out that some other people managed to make mount
> use the uid of the initiating user rather than 'root'(uid=0) (though they seem
> to have other problems...).
>
> I'm not quite sure what is wrong with my setup and therefore i tried to dig
> into the code of gssd. The only thing i found is that the uid (0 in my case)
> is read from a file "clntXX/krb5" (within a pipefs) which is obviously
> written by the kernel.
>
> A kernel update to 2.6.32-19 (i'm using ubuntu karmic on an amd64 machine)
> didn't make it any better.
>
> Complete Log (client): http://pastebin.com/s7B2W7ie
> The user ticket (i'm running the mount-command from an account of a user which
> is authenticated via kerberos (MIT Kerberos5)) resided in
> /tmp/krb5cc_10002_H6OYu0
> Here's what klist said http://pastebin.com/Lrrs3AwM
> And this is the client's krb5.conf: http://pastebin.com/JChsVNJQ
>
> I'm really desperate now because i've been working on this problem for nearly
> two weeks now and i couldn't get by...
>
> Can you suggest me how to specify which user should be utilized to carry out
> the mount? (Did I misconfigure something?)
>
>
> By the way i've already downloaded the source-code of the nfs-utils
> (ver. 1.2.0) and modified
> void handle_krb5_upcall(struct clnt_info *clp)
> from
> gssd/gssd_proc.c
> to statically set uid to 10002 (just for testing what will happen) and it's
> pretty interesting what comes out:
> http://pastebin.com/Qi1rWMLC
>
> Thanks in advance!
By the looks of your /etc/fstab entry, the system (root) will try to
mount /mnt/net automatically. You could try adding the "noauto"
option and then manually issuing the mount command as the user. (Or
use automount?)
K.C.
On Thursday 08 April 2010 16:18:11 you wrote:
> On Wed, Apr 7, 2010 at 7:11 PM, <[email protected]> wrote:
> >> By the looks of your /etc/fstab entry, the system (root) will try to
> >> mount /mnt/net automatically. You could try adding the "noauto"
> >> option and then manually issuing the mount command as the user. (Or
> >> use automount?)
> >> K.C.
> >
> > I'm pretty sure that it doesn't try to automatically mount the share on
> > startup since there is no log entry that would indicate such an attempt.
> > I already tried to do the mount as a user (which is authenticated via
> > kerberos such that there is a valid ticket for that user) the logs (that
> > i have posted) are showing what comes out of it. If I try to do the mount
> > without the fstab- entry (i.e. mount -t nfs4 -o sec=krb5p dnsdhcp:/
> > /mnt/net) it is being rejected on the grounds that only root can perform
> > a mount. 'sudo' doesn't work currently (i've got some problems with my
> > PAM config for sudo) so I haven't had any chance to try it out...
> >
> > I've already set up automount but it actually does exactly the same as if
> > I ran mount manually as described above.
> >
> > I'm totally confused because I don't understand what people like
> > http://thread.gmane.org/gmane.linux.nfsv4/5893
> > might have done to perform a mount with normal user privileges. If it was
> > really mandatory to be root (as stated by Andy Adamson in the other
> > message) then I wouldn't really understand why they should have
> > implemented the uid passing using that pipefs file....
>
> Hello Tom,
>
> To allow non-root users to do the mount, add the "user" option to the
> entry in /etc/fstab. Then the user with uid 10002 should be able to
> kinit and then mount. (Note that in this case, there is no need for
> the "-n" option to rpc.gssd.)
>
> K.C.
>
I've already added have the "user"-option in my fstab (I also reported that in
my very first message) such that the entry looks like:
dnsdhcp:/ /mnt/net nfs4 sec=krb5p,user 0 0
To express it more clearly:
The user with uid=10002 (username = tomkrb) can do a kinit but i guess it
doesn't need to if it is already logged into a bash-console using pam_krb5-
authentication-module. A ticket already exists for that session in the /tmp
directory and if i modify the "void handle_krb5_upcall(struct clnt_info
*clp)"-function in gssd_proc.c to not use the uid which is passed by the
kernel but rather use 10002 (statically) that ticket is also accepted.
Meanwhile i succeeded in getting sudo working. Performing
sudo mount -t nfs4 -o sec=krb5p dnsdhcp:/ /mnt/net
from a (physical) console where tomkrb (uid=10002) is logged in also results
in uid=0 being passed instead of uid=10002.
Is it possible to understand what i'd like to do at all?
--
Lehrstuhl f?r Softwaretechnik und Programmiersprachen
Fakult?t WIAI, Universit?t Bamberg, 96045 Bamberg
Email: [email protected]
Web: http://www.swt-bamberg.de/
Tel.: 0951 863-3852 / Fax: 0951 863-3855
On Apr 7, 2010, at 10:37 AM, Tom wrote:
> I'm trying to set up a kerberized NFSv4 client to mount a share
> using a local
> ticket (obtained by PAM when the user logged into the shell) instead
> of a
> machine specific ticket (i.e. I'd like to do user-based
> authorization). I
> already managed to get machine based authentification/authorization
> working for
> a test but i can't (and i don't want to) use local keytab files for
> storing the
> machine keys on the client machines in my production environment.
>
> I'm running the rpc.gssd with the "-n -vvv -rrr" to make it consider
> user
> tickets too.
> Now, when I try to mount the share to "/mnt/net" (the according
> fstab-line
> looks like "dnsdhcp:/ /mnt/net nfs4 sec=krb5p,user 0 0") the
> credentials
> cache of the user which is doing the mount is not being used. The
> second
> log message reads
> "rpc.gssd[888]: getting credentials for client with uid 0 for server
> <srvname>"
> Googling around a bit i found out that some other people managed to
> make mount
> use the uid of the initiating user rather than 'root'(uid=0) (though
> they seem
> to have other problems...).
>
> I'm not quite sure what is wrong with my setup and therefore i tried
> to dig
> into the code of gssd. The only thing i found is that the uid (0 in
> my case)
> is read from a file "clntXX/krb5" (within a pipefs) which is obviously
> written by the kernel.
This means that you are performing the mount from a process whose uid
= 0, e.g, your local linux user is root.
Don't you need to be local linux user root to perform any mount?
So, you need to associate the Kerberos principal of the PAM ticket
with the UID=0.
-->Andy
>
> A kernel update to 2.6.32-19 (i'm using ubuntu karmic on an amd64
> machine)
> didn't make it any better.
>
> Complete Log (client): http://pastebin.com/s7B2W7ie
> The user ticket (i'm running the mount-command from an account of a
> user which
> is authenticated via kerberos (MIT Kerberos5)) resided in
> /tmp/krb5cc_10002_H6OYu0
> Here's what klist said http://pastebin.com/Lrrs3AwM
> And this is the client's krb5.conf: http://pastebin.com/JChsVNJQ
>
> I'm really desperate now because i've been working on this problem
> for nearly
> two weeks now and i couldn't get by...
>
> Can you suggest me how to specify which user should be utilized to
> carry out
> the mount? (Did I misconfigure something?)
>
>
> By the way i've already downloaded the source-code of the nfs-utils
> (ver. 1.2.0) and modified
> void handle_krb5_upcall(struct clnt_info *clp)
> from
> gssd/gssd_proc.c
> to statically set uid to 10002 (just for testing what will happen)
> and it's
> pretty interesting what comes out:
> http://pastebin.com/Qi1rWMLC
>
> Thanks in advance!
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs"
> in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> By the looks of your /etc/fstab entry, the system (root) will try to
> mount /mnt/net automatically. You could try adding the "noauto"
> option and then manually issuing the mount command as the user. (Or
> use automount?)
> K.C.
I'm pretty sure that it doesn't try to automatically mount the share on
startup since there is no log entry that would indicate such an attempt.
I already tried to do the mount as a user (which is authenticated via kerberos
such that there is a valid ticket for that user) the logs (that i have posted)
are showing what comes out of it. If I try to do the mount without the fstab-
entry (i.e. mount -t nfs4 -o sec=krb5p dnsdhcp:/ /mnt/net) it is being
rejected on the grounds that only root can perform a mount. 'sudo' doesn't
work currently (i've got some problems with my PAM config for sudo) so I
haven't had any chance to try it out...
I've already set up automount but it actually does exactly the same as if I
ran mount manually as described above.
I'm totally confused because I don't understand what people like
http://thread.gmane.org/gmane.linux.nfsv4/5893
might have done to perform a mount with normal user privileges. If it was
really mandatory to be root (as stated by Andy Adamson in the other message)
then I wouldn't really understand why they should have implemented the uid
passing using that pipefs file....
On Thursday 08 April 2010 20:58:49 you wrote:
> Sorry, I missed that, or forgot. And you still get "mount : only root
> can mount ..." if you do "mount /mnt/net" as tomkrb ?? If so, that
> seems like a bug.
No, with that entry each user is able to invoke mount. The problem is that
mount is carried out with uid=0 then.
> Yes, because under sudo, you are running as root.
obviously...
I'm wondering if there's a chance to run mount with a non-root uid at all. On
the other hand is that really needed? I mean I just want it to pass the
calling user's uid to the rpc.gssd...
By the way the rpcsec_gss_krb5 is loaded.
> You said you had this working for the case where root did the mount
> using a keytab though, correct? It can also be caused by a mismatch
> of sec flavors. (i.e., is the server exporting with krb5p?)
Yes, it worked fine when i used a keytab-file with the key for the client-
machine-principal in it. When i issued mount everything worked fine. The
problem with this kind of setup is just that this would simply be some kind of
host-based authentication and I can't trust the people which will use the
clients as much to use a keytab file. They could simply boot from a LiveCD,
memstick etc. and steal that keytab file...
I've double checked that krb5p is specified in the server's /etc/exports as
well as in the client's /etc/fstab (i've also tried it with "krb5" on both
sides but that didn't make any difference) .
Does it matter whether those two flags match before the security context is
completely established at all?
On Fri, Apr 9, 2010 at 5:15 AM, Thomas Wunder
<[email protected]> wrote:
> On Thursday 08 April 2010 20:58:49 you wrote:
>> Sorry, I missed that, or forgot. ?And you still get "mount : only root
>> can mount ..." if you do "mount /mnt/net" as tomkrb ?? ?If so, that
>> seems like a bug.
>
> No, with that entry each user is able to invoke mount. The problem is that
> mount is carried out with uid=0 then.
>
>> Yes, because under sudo, you are running as root.
> obviously...
>
> I'm wondering if there's a chance to run mount with a non-root uid at all. On
> the other hand is that really needed? I mean I just want it to pass the
> calling user's uid to the rpc.gssd...
>
> By the way the rpcsec_gss_krb5 is loaded.
>
>> ?You said you had this working for the case where root did the mount
>> using a keytab though, correct? ?It can also be caused by a mismatch
>> of sec flavors. ?(i.e., is the server exporting with krb5p?)
> Yes, it worked fine when i used a keytab-file with the key for the client-
> machine-principal in it. When i issued mount everything worked fine. The
> problem with this kind of setup is just that this would simply be some kind of
> host-based authentication and I can't trust the people which will use the
> clients as much to use a keytab file. They could simply boot from a LiveCD,
> memstick etc. and steal that keytab file...
> I've double checked that krb5p is specified in the server's /etc/exports as
> well as in the client's /etc/fstab (i've also tried it with "krb5" on both
> sides but that didn't make any difference) .
>
> Does it matter whether those two flags match before the security context is
> completely established at all?
I tried a user mount yesterday and it worked fine, but I had a keytab
on the machine. Looking closer today, I see two upcalls coming up for
the user-mount case. The first has uid 0, as you say. The second was
with my uid. Removing my keytab causes the mount to fail as you are
seeing. Sorry to take so long to figure that out.
I don't think this has always been the case. Something might have
changed with the new kernel mount code?
Copying Chuck to see if he knows more...
K.C.
On Thu, Apr 8, 2010 at 11:39 AM, Thomas Wunder
<[email protected]> wrote:
> On Thursday 08 April 2010 16:18:11 you wrote:
>> On Wed, Apr 7, 2010 at 7:11 PM, ?<[email protected]> wrote:
>> >> By the looks of your /etc/fstab entry, the system (root) will try to
>> >> mount /mnt/net automatically. ?You could try adding the "noauto"
>> >> option and then manually issuing the mount command as the user. ?(Or
>> >> use automount?)
>> >> K.C.
>> >
>> > I'm pretty sure that it doesn't try to automatically mount the share on
>> > startup since there is no log entry that would indicate such an attempt.
>> > I already tried to do the mount as a user (which is authenticated via
>> > kerberos such that there is a valid ticket for that user) the logs (that
>> > i have posted) are showing what comes out of it. If I try to do the mount
>> > without the fstab- entry (i.e. mount -t nfs4 -o sec=krb5p dnsdhcp:/
>> > /mnt/net) it is being rejected on the grounds that only root can perform
>> > a mount. 'sudo' doesn't work currently (i've got some problems with my
>> > PAM config for sudo) so I haven't had any chance to try it out...
>> >
>> > I've already set up automount but it actually does exactly the same as if
>> > I ran mount manually as described above.
>> >
>> > I'm totally confused because I don't understand what people like
>> > http://thread.gmane.org/gmane.linux.nfsv4/5893
>> > might have done to perform a mount with normal user privileges. If it was
>> > really mandatory to be root (as stated by Andy Adamson in the other
>> > message) then I wouldn't really understand why they should have
>> > implemented the uid passing using that pipefs file....
>>
>> Hello Tom,
>>
>> To allow non-root users to do the mount, add the "user" option to the
>> entry in /etc/fstab. ?Then the user with uid 10002 should be able to
>> kinit and then mount. ?(Note that in this case, there is no need for
>> the "-n" option to rpc.gssd.)
>>
>> K.C.
>>
> I've already added have the "user"-option in my fstab (I also reported that in
> my very first message) such that the entry looks like:
> dnsdhcp:/ ?/mnt/net nfs4 ? sec=krb5p,user ? ? ? ? ?0 ? ? ? 0
Sorry, I missed that, or forgot. And you still get "mount : only root
can mount ..." if you do "mount /mnt/net" as tomkrb ?? If so, that
seems like a bug.
> To express it more clearly:
> The user with uid=10002 (username = tomkrb) can do a kinit but i guess it
> doesn't need to if it is already logged into a bash-console using pam_krb5-
> authentication-module. A ticket already exists for that session in the /tmp
> directory and if i modify the "void handle_krb5_upcall(struct clnt_info
> *clp)"-function in gssd_proc.c to not use the uid which is passed by the
> kernel but rather use 10002 (statically) that ticket is also accepted.
>
> Meanwhile i succeeded in getting sudo working. Performing
> sudo mount -t nfs4 -o sec=krb5p dnsdhcp:/ /mnt/net
> from a (physical) console where tomkrb (uid=10002) is logged in also results
> in uid=0 being passed instead of uid=10002.
Yes, because under sudo, you are running as root.
> Is it possible to understand what i'd like to do at all?
Apparently I also skipped the end of your original message where you
overrode the UID and the gss context exchange seemingly worked, but
then failed to write the context to the kernel. This has usually been
caused by the proper kernel module (rpcsec_gss_krb5) not being loaded.
You said you had this working for the case where root did the mount
using a keytab though, correct? It can also be caused by a mismatch
of sec flavors. (i.e., is the server exporting with krb5p?)
K.C.
Is this the infamous 'test-export' call that should be removed?
-->Andy
On Fri, Apr 9, 2010 at 10:50 AM, Kevin Coffman <[email protected]> wro=
te:
> On Fri, Apr 9, 2010 at 5:15 AM, Thomas Wunder
> <[email protected]> wrote:
>> On Thursday 08 April 2010 20:58:49 you wrote:
>>> Sorry, I missed that, or forgot. =A0And you still get "mount : only=
root
>>> can mount ..." if you do "mount /mnt/net" as tomkrb ?? =A0If so, th=
at
>>> seems like a bug.
>>
>> No, with that entry each user is able to invoke mount. The problem i=
s that
>> mount is carried out with uid=3D0 then.
>>
>>> Yes, because under sudo, you are running as root.
>> obviously...
>>
>> I'm wondering if there's a chance to run mount with a non-root uid a=
t all. On
>> the other hand is that really needed? I mean I just want it to pass =
the
>> calling user's uid to the rpc.gssd...
>>
>> By the way the rpcsec_gss_krb5 is loaded.
>>
>>> =A0You said you had this working for the case where root did the mo=
unt
>>> using a keytab though, correct? =A0It can also be caused by a misma=
tch
>>> of sec flavors. =A0(i.e., is the server exporting with krb5p?)
>> Yes, it worked fine when i used a keytab-file with the key for the c=
lient-
>> machine-principal in it. When i issued mount everything worked fine.=
The
>> problem with this kind of setup is just that this would simply be so=
me kind of
>> host-based authentication and I can't trust the people which will us=
e the
>> clients as much to use a keytab file. They could simply boot from a =
LiveCD,
>> memstick etc. and steal that keytab file...
>> I've double checked that krb5p is specified in the server's /etc/exp=
orts as
>> well as in the client's /etc/fstab (i've also tried it with "krb5" o=
n both
>> sides but that didn't make any difference) .
>>
>> Does it matter whether those two flags match before the security con=
text is
>> completely established at all?
>
> I tried a user mount yesterday and it worked fine, but I had a keytab
> on the machine. =A0Looking closer today, I see two upcalls coming up =
for
> the user-mount case. =A0The first has uid 0, as you say. =A0The secon=
d was
> with my uid. =A0Removing my keytab causes the mount to fail as you ar=
e
> seeing. =A0Sorry to take so long to figure that out.
>
> I don't think this has always been the case. =A0Something might have
> changed with the new kernel mount code?
>
> Copying Chuck to see if he knows more...
>
> K.C.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" =
in
> the body of a message to [email protected]
> More majordomo info at =A0http://vger.kernel.org/majordomo-info.html
>
On 04/09/2010 10:50 AM, Kevin Coffman wrote:
> On Fri, Apr 9, 2010 at 5:15 AM, Thomas Wunder
> <[email protected]> wrote:
>> On Thursday 08 April 2010 20:58:49 you wrote:
>>> Sorry, I missed that, or forgot. And you still get "mount : only root
>>> can mount ..." if you do "mount /mnt/net" as tomkrb ?? If so, that
>>> seems like a bug.
>>
>> No, with that entry each user is able to invoke mount. The problem is that
>> mount is carried out with uid=0 then.
>>
>>> Yes, because under sudo, you are running as root.
>> obviously...
>>
>> I'm wondering if there's a chance to run mount with a non-root uid at all. On
>> the other hand is that really needed? I mean I just want it to pass the
>> calling user's uid to the rpc.gssd...
>>
>> By the way the rpcsec_gss_krb5 is loaded.
>>
>>> You said you had this working for the case where root did the mount
>>> using a keytab though, correct? It can also be caused by a mismatch
>>> of sec flavors. (i.e., is the server exporting with krb5p?)
>> Yes, it worked fine when i used a keytab-file with the key for the client-
>> machine-principal in it. When i issued mount everything worked fine. The
>> problem with this kind of setup is just that this would simply be some kind of
>> host-based authentication and I can't trust the people which will use the
>> clients as much to use a keytab file. They could simply boot from a LiveCD,
>> memstick etc. and steal that keytab file...
>> I've double checked that krb5p is specified in the server's /etc/exports as
>> well as in the client's /etc/fstab (i've also tried it with "krb5" on both
>> sides but that didn't make any difference) .
>>
>> Does it matter whether those two flags match before the security context is
>> completely established at all?
>
> I tried a user mount yesterday and it worked fine, but I had a keytab
> on the machine. Looking closer today, I see two upcalls coming up for
> the user-mount case. The first has uid 0, as you say. The second was
> with my uid. Removing my keytab causes the mount to fail as you are
> seeing. Sorry to take so long to figure that out.
>
> I don't think this has always been the case. Something might have
> changed with the new kernel mount code?
>
> Copying Chuck to see if he knows more...
I don't know anything about these upcalls, sorry.
--
chuck[dot]lever[at]oracle[dot]com
> I don't know anything about these upcalls, sorry.
But maybe you know which piece of code puts the uid into
/var/lib/nfs/rpc_pipefs/clntXX/krb5
It's hard for me to find an entry point to dig into the nfs kernel code on my
own as i haven't got any experience with linux "filesystem drivers" yet...
We just need to find out why it always puts "0" there instead of the real uid
of the user which invoked the mound command...