DragonFly kernel List (threaded) for 2004-03
dragonfly and cfsd: nfs client troubles?
I was just playing around with CFS in DragonFlyBSD a bit, and found
out a slight discrepancy:
(this is a rather long introduction. To make a long story short, I
think that the wrong NFS request credentials are passed in the
structure pointed to by svc_req::rq_clntcred - It always passes^ 0 in
the aup_uid field of the authunix_parms structure).
I'm following the CFS setup guides available, and all works well,
until I attach a directory and try to access the "clear-text" version:
asf@carpenter:~/tmp/cfstest$ cattach dir
asf@carpenter:~/tmp/cfstest$ ls -lao /crypt
drwxrwxrwx 4 root wheel - 8192 Mar 21 18:40 .
drwxr-xr-x 19 root wheel - 512 Mar 21 15:40 ..
drwx------ 2 asf asf - 512 Mar 21 17:23 dir
asf@carpenter:~/tmp/cfstest$ ls -lao /crypt/dir
ls: dir: Operation not permitted
ow. For those of you unfamiliar with CFS, the CFSd checks the
credentials (specifically, the UID) in the request against those of
the user who attached the directory. If they don't match, it gives the
I tracked this down in the cfsd code, and all svc_req request
structures' rq_clntcred pointers are for UID 0. Is that a bug in the
nfs code? Or am I missing something in my setup? This is the
/etc/exports file I'm using (fairly standard, I suppose):
and this is the relevant part of /etc/rc.conf:
Nothing very special, I suppose.
Of course, when I attach the directory as UID 0 and access it as UID
0, it works. This isn't very useful, though, as I'd like a regular
user to be able to access files on CFS.
Does anybody have an idea what's going wrong here (apart from the lack
of GEOM or some more sensible FS encryption scheme <-;)?
Thanks a lot,
Andreas Fuchs, <asf@xxxxxxxxxxx>, asf@xxxxxxxxx, antifuchs