NFS client and UIDs and GIDs
strauman at slac.stanford.edu
Mon Aug 1 21:19:07 CDT 2011
So far, the NFS client uses the second-variant.
At mount-time, the uid/gid is specified by the user
and an RPC authentication handle for this uid/gid
pair is created and used for all further communication with
the server (primarily for efficiency reasons on low-resource
platforms). It would maybe be preferable to construct
a new authentication handle for each NFS call based on
geteuid()/getgid() of the caller but that is just not
the way it is implemented right now.
Hence, the straightforward way would be to use the uid/gid
that are stored in the 'Nfs' struct. However, there is one
special case: if the user does not specify a uid/gid
explicitly at mount time then the authentication handle
is built using the return values of geteuid()/getgid().
Hence, a proper implementation would have to extract the
uid/gid from the authentication handle stored in the
RpcUdpServerRec associated with the NFS server.
IMO, the proper implementation (w/o major rework and changing
semantics) would be
- the places marked with TODO should use 'node->nfs->uid/node->nfs->gid'
- the code that sets 'nfs->uid/nfs->gid' (rtems_nfs_initialize()) should
extract the uid/gid from 'nfsServer->auth'.
However, since that step may not be possible using the existing API
the code in 'buildIpAddr()' could use geteuid()/getegid() instead
of using RPCIOD_DEFAULT_ID as a default. This should guarantee that
nfs->uid/nfs->gid are always valid.
On 08/01/2011 02:48 AM, Sebastian Huber wrote:
> in the mknod() handler of the NFS client there is currently a TODO:
> /* TODO: either use our uid or use the Nfs credentials */
> SERP_ARGS(node).createarg.attributes.uid = 0;
> SERP_ARGS(node).createarg.attributes.gid = 0;
> I have to implement this, because the 0 identifiers are not suitable for
> The first variant is:
> SERP_ARGS(node).createarg.attributes.uid = geteuid();
> SERP_ARGS(node).createarg.attributes.gid = getegid();
> The second variant is:
> SERP_ARGS(node).createarg.attributes.uid = /* some value specified at
> mount time */;
> SERP_ARGS(node).createarg.attributes.gid = /* some value specified at
> mount time */;
> The first variant has the benefit that you can change the value later
> and the value may be different for different threads. On the other hand
> local and remote UIDs and GIDs may be unrelated. For simplicity I would
> choose the first variant.
> What do you think?
> Best regards,
More information about the rtems-users