Re: [PATCH] New function (libfshelp) fshelp_cancontrol

[Neal H Walfield]

> I don't think it much matters which of these criteria we use.  
> 
> If pfinet's style is preferable, then it should at least consistently track
> the st_uid/st_gid of the underlying node if it passes through changes (as
> trivfs filesystems usually do).  Thus the interface in my example code
> above, where fshelp_isroot takes a struct stat containing the last stored
> state of the underlying node.

I feel that we should use, effectively, the same criteria as that to
determine if a process can send a signal to another process.  My
rational is the following:  a process attempting to control a resource
always uses its strongest identification, however, if a resource allowed
itself to be obtained by its weakest identification, there are a lot of
places for potential holes.  Consider the following:

        $ login neal
        Password:
        ...
        $ addauth --pid=$$ root
        Password:
        $ settrans -ac /foo ...

In this case, only root would be able to control the resource.  If we
used my old logic, anyone that could get access to my identification
could also control the resource.

Thus, I conclude that a resource should only recognize the effective id
of the user that creates it (unless that is changed -- i.e. we respect
chown).

If you agree with this logic, then there is nothing different between
fshelp_isowner and fshelp_isroot and we can just use fshelp_isowner.
However, the interface to fshelp_isowner is flawed (especially if we
want to use it interchangeably with fshelp_isroot).  If should be:

        error_t
        fshelp_isowner (uid_t uid, gid_t gid, struct iohelp *user);

If you agree, I will cook up a patch.

pgppvmqAdS5W0.pgp
Description: PGP signature