NT ACL / Security descriptor checking function

[Luke Kenneth Casson Leighton]

On Sat, 12 Feb 2000, David Collier-Brown wrote:

> Luke Kenneth Casson Leighton wrote:
> > this was discussed four to five months ago, my recommendation was to do it
> > the other way round: map immediately out as soon as possible to NT
> > security descriptors, and maintain for as long as possible NT SDs before
> > converting to, say... POSIX or Unix ACls or file permissions.
> > 
> > reason: you don't want to impose a restriction, in the file-system
> > example, of mapping to POSIX-based ACLs, only to find later that the
> > underlying filesystem actually supports a much richer ACL implementation
> > thatn the [limited] POSIX one, or even fully supports NT security
> > descriptors, such as the linux NTFS drivers.
> 
> 	I mildly agree: I speculate you have two modules,
> 	one which just looks up the ACLS in an underlying
> 	filesystem that supports them all, or supports
> 	a superset. This may well be a stub unless you happen
> 	to have linux NTFS handy...

ok.  what you do is you implement vfs-table "modules" that handle
different filesystem mappings.  the API takes NT security descriptor.

for unix-perms, the vfs-chmodACL function is implemented using jeremy's
code in nttrans.c  it takes a security descriptor, and depending on
whether the target is a dir or a file, you map it to a subset of unix
ugo+rwx permissions.

for POSIX-acl-perms, the vfs-chmodACL function is implemented ccording to
the guidelines described in www.fas.org/irp/nsa/rainbow/tg020-a.htm or if
someone want to go through the process of reinventing the wheel, they can.

for the NTFS driver (which apparently hasn't been trhoguh development for
a year, is read-only and is likely to be dropped, i presume the issue is
too sticky: i'm not surprised!) or for other SD-perms-based filesystems,
the vfs-chmodACL function drops the binary security-descriptor straight to
disk.