> 1. NFS3 mounts with AUTH_DES authentication work fine. There looks like to
> be some caching errors with NFS2 however: suppose user A has
> properly keylogged in, and user B is not. If I issue an NFS
> readdir operation (such like 'ls /mnt', where /mnt is the
> mount point of the NFS filesystem) as user A, and sortly
> after exactly the same operation as user B, the operation
> eventually succeeds. Turning on debugging shows that in the
> second case, the DES credential for user B is created
> (i.e. the crcreate() function of struct rpc_authops is
> called), but it is never sent to the NFS server for
> validation. If I try a different NFS operation as user B, I
> get a 'Permission denied' message as expected.
This is normal. If information is cached, then for NFSv2 the file's
standard permission bits are consulted rather than issuing a new RPC
request. NFSv3, on the other hand, has a special 'ACCESS' call which
is used to provide more fine-grained access control.
> 2. On an SMP kernel, the credential creation function (member crcreate() of
> struct rpc_authops) gets called with
> current->(uid|euid|suid|fsuid) all equal to 0, which makes
> it impossible to identify the user for whom the credential
> is to be created for. It does not happen on a non-SMP kernel
> (both kernels are compiled from the same source tree but are
> running on different machines).
Which kernel is this? Does it happen in the stock kernel too?
In principle, neither RPC nor NFS should touch those fields, and since
the credentials of the task should always be set before an
asynchronous request is put on the RPCIOD queue, 'current' should
point to the current process upon entry to crcreate().
Cheers,
Trond
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/