Hi Ivan,
Very good questions !
As I am not sure I can answer them fully, I am cc'ing to the
fuse devel list for more insight into them.
Ivan Zakharyaschev wrote:
> Hello!
>
> When reading the ntfs-3g-1.2712SR.1 code, I noticed in ntfs_set_mode()
> in security.c the following check:
>
> if (!processuid || (uid == processuid)) {
> ...
> } else {
> errno = EPERM;
> res = -1; /* neither owner nor root */
> }
>
> Does this mean that ntfs-3g does the rude check for processuid==0 and
> ignores the actually applicable delicate capability, CAP_FOWNER? If
> so, it's a pity, it would be nice if the general linux capabilities
> system would work for NTFS as well.
>
True, this could be improved.
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.
Can other fuse file system developer give indications
on how they used the capabilities and accessed the
supplementary group list ?
> 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.
I found the opposite happened when switching from
kernel 2.6.24 to 2.6.25 (I am not sure whether this is
due to a fuse change or a kernel one). Fuse or the
kernel happens to make fewer checks for the sticky
bit than it previously did, so I had to put more checks
into the driver.
Note however that currently, fuse can only get the file
attributes from getattr(), which implies getting all the
attributes. This probably has an impact on how the
caches are shared between fuse and the driver. The
attribute cacheing has to be improved anyway to cope
with attributes of hard linked files.
> And also, I haven't yet understood how the POSIX ACLs implementation
> work. Does ntfs-3g just map between NTFS and POSIX ACLs and relegate
> permission checking to a general (system-wide?) POSIX ACL permission
> checking procedure, or does it again re-implement the POSIX ACLs
> checking logic (although it could be thought to be a
> filesystem-independent system-wide common procedure)?
>
The Posix ACL implementation works roughly the same
way, which means the permissions checking has been
rewritten. I also feed this could be done within fuse
and usable for any file system.
The merging of changes to an ACL into the current
ACL as a consequence of chmod or setfacl is already
done system-wide by fuse (or the kernel ?).
> Many thanks for creating this very useful driver!
>
My own part in it is minimal. My pleasure nevertheless.
Regards
Jean-Pierre
> Best regards,
>
>
-------------------------------------------------------------------------
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
