Hi Jean-Pierre,
Thanks for the answers! Now I have a better understanding of the situation.
On Thu, Aug 7, 2008 at 12:41 PM, Jean-Pierre André
<[EMAIL PROTECTED]> wrote:
> AFAIK, the only information fuse gives about the process
> on behalf of which the driver is running are its pid, uid
> and gid. The only way I know to get the process capabilities
> is interpreting a file in /proc, which I feel inefficient.
> However I have had to do so to get the supplementary
> groups, so I know it is possible.
It's written there exists a Linux-specific (unfortunately) API for this:
capgetp fills an existing cap_d, see cap_init(3), with the
process capabilities of the process indicated by pid. This
information
can also be obtained from the /proc/<pid>/status file.
>> And also this thing made me think of a more general issue. (I don't
>> know much about FUSE, so perhaps I'm misunderstanding something; and I
>> would like to know more.)
>>
>> This code which checks whether the user has enough rights makes an
>> impression of re-implementing one more time the general linux logic
>> for permission checking, and it doesn't feel right. Isn't it possible
>> in FUSE to use the system procedure for permission checking as the
>> default? Why should at all this ntfs-3g code care about whether it
>> should check for CAP_FOWNER or for processuid==0 or for something else
>> (when a new version of linux with different logic is out) -- can't it
>> just tell the kernel all the owner and permission information and let
>> it decide whether the operation is allowed?
>>
>
> I agree, and I have already suggested the same on the
> fuse list. Fuse could indeed check the rights based on
> the file owner and permissions, the driver being only
> responsible for storing and retrieving the attributes.
But, I believe, having the possibility to override the common
permission checking logic with own rules in the driver is also a good
thing: for example, someone might want to use this flexibility to
implement an emulation of the original Windows access rules. So, not
hardcoding the default linux logic into FUSE or ntfs-3g, but rather
modularizing it seems to be reasonable (and making the default
permission checking module as tiny as possible, relegating the work to
the default mechanisms in the kernel, if it is possible at all).
Regards,
--
Ivan
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
ntfs-3g-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ntfs-3g-devel
