Subject: Re: vfs modifications or alternatives
To: Matthew Mondor <mmondor@gobot.ca>
From: Bill Studenmund <wrstuden@netbsd.org>
List: tech-kern
Date: 07/10/2002 12:42:17
Weird, either your system's clock is off, or it waited almost a week to
mail your message. ;-)

On Thu, 27 Jun 2002, Matthew Mondor wrote:

> Has there been any previous work or thread about vfs/syscall additions to
> allow supporting permissions of non-unix filesystems? The system would
> simply permit to obtain or set the particular file permissions from/to a
> data block or such... and would allow for instance a unix system to
> archive say, NTFS trees preserving permissions...

No, but you could use fcntl(2) for that. There is a range of fcntl values
(ones with F_FSCTL from <sys/fcntl.h> set) that are passed to VOP_FCNTL().
That would be an easy way to get info to/from userland, say for backing up
NTFS file systems.

> Of course the extentions would only be allowed to use by uid 0, and would
> also permit a userspace environment to run a daemon with superuser
> privileges, managing filesystem permissions for a lower user subsystem...

Well, since what a file system does with VOP_FCNTL is its own business, it
can be restrictive or not.

If you want to play with daemons, though, you can use fhopen() to help the
daemon open files.

> This could for instance be interesting to wine and other win32 API
> implementations on unix systems, for Amiga emulators where affs
> permissions could be evaluated and changed, etc.
>
> Obviously the kernel would perform no evaluation whatsoever on the
> permission data, it merely would only consist of user-settable flags.

:-)

Take care,

Bill