NFS client and UIDs and GIDs

Till Straumann strauman at slac.stanford.edu
Mon Aug 1 21:19:07 CDT 2011


Sebastian.

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.

- Till


On 08/01/2011 02:48 AM, Sebastian Huber wrote:
> Hello,
>
> 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
> us.
>
> 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,
> Sebastian
>




More information about the rtems-users mailing list