[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] New function (libfshelp) fshelp_cancontrol

From: Neal H Walfield
Subject: Re: [PATCH] New function (libfshelp) fshelp_cancontrol
Date: Fri, 20 Apr 2001 20:03:03 +0200
User-agent: Mutt/1.3.15i

> 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
        $ addauth --pid=$$ root
        $ 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

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:

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

If you agree, I will cook up a patch.

Attachment: pgppvmqAdS5W0.pgp
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]