Date: Wed, 14 Mar 2001 05:33:07 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: babkin@bellatlantic.net (Sergey Babkin) Cc: rwatson@FreeBSD.ORG (Robert Watson), msmith@FreeBSD.ORG (Mike Smith), freebsd-arch@FreeBSD.ORG, bright@wintelcom.net (Alfred Perlstein) Subject: Re: how do I get sysctl node names ? Message-ID: <200103140533.WAA03974@usr05.primenet.com> In-Reply-To: <3AAEE129.43C6ECBB@bellatlantic.net> from "Sergey Babkin" at Mar 13, 2001 10:10:33 PM
next in thread | previous in thread | raw e-mail | index | archive | help
> NetWare seems to have worked for quite a long time with ACLs and I
> think that they have found a great solution that makes the ACLs a lot
> cleaner: inheritance of the ACLs down the directories. But obviously
> the implementation of the inheritance is not so cheap.
>
> Another thing I liked in Netware is the hierarchies of groups: a
> group may be made a member of another group, and the control over
> the group permissions can be delegated to other users. This part
> seems to be easy enough to implement over the classic Unix
> model at the user level.
I implemented this in UnixWare; I'm the primary author of NXFS,
the NetWare eXtended File System, and attributed FS that was
used to provide these semantics on NetWare for UNIX running on
UnixWare, AIX, and Solaris.
I have to say that the implementation I used was much simpler:
I defined a "secondary inode" field using spare space in the
main inode, and put a second file fork in it. Then I modified
the directory reference code in "fsck" to not require directory
entries for it, and instead require primaries to point to the
secondary.
Secondary inodes don't have any lonk count issues. You can also
include a primary pointer in the secondary, as a backwards
reference.
To deal with the inheritance, which is actually really reverse
inheritance, given the NetWare semantics, I disallowed hard
links on directories. This made parent pointers for directories
possible, and unambiguous.
For file attributes, you can just look at the parent reference
path for the file. This is known (and cached in the DNLC) on
lookup.
You can also be more sneaky about hard link implementation,
which would let you maintain parent pointers correctly for
any link access path, but since FreeBSD has vm_object_t
issues with the vnode being owned by the system instead of the
FS, you won't be able to do this without a bit more work than
it first appears it would take. Looking up the files isn't
that hard, since there is locality. Plus, if you can get at
the file, the attributes would inherit up for any path, and let
you get at the file anyway, so you don't care about the files
when it comes to inheritance, only the operations where you
link an attributed file into a directory where it wasn't before,
and want to propagate rights upward.
For backup, I cheated: I could set a variable which would make
the directory lookups return the fork name of files with forks;
this wasn't strictly necessary, but it works.
For the forks themselves, I attempted to use a POSIX namespace
incursion. I settled on using a ^A as the first character to
select the fork on the terminal object; this was driven both
by the fact that I only needed 128 character file names, and
the fact that the lookup routine in SVR4 derived systems can't
correctly propagate a POSIX namespace escape ("//<namespace>/<path>")
on a per component basis. FreeBSD has this same design flaw, but
on FreeBSD, it's easily fixable, so you don't have to eat the
first character of each component, like I did.
We had to do an FS at the time to resolve the local application
vs. client application coherency problem; not only for mandatory
and advisory locking, but also for client cache invalidation.
My ideal approach would be to fold the namespace, and turn
each file into a directory, and use the namespace escape to
select real files in the directory ("data", "rsrc", etc.), but
the stacking in FreeBSD isn't quite up to snuff, though the
5.x developement branch, which isn't at all useful for anything
you need to put on a production server, IMO, is coming quite
close to stacking finally being happy.
Backup in the folded namespace case would be done on an exposed
view of the underlying ("unfolded") FS namespace, and so would
be pretty trivial, actually: expose, backup, hide, or just put
the exposure in a publically inaccessable subtree, and use the
upper layer mount to expose it somewhere globally accessible.
PS: the problems that have been noted elsewhere apply doubly to
NFS mounts: no way to deal with ACL stuff there. The namespace
escape may or may not work (depends on if the leading "//" is
incorrectly compressed to just "/" before being proxied, or if
the OS doing the proxying is POSIX compliant). My recommendation
is to use a descriptor proxy (see the FICUS papers by John
Heidemann), since this would let you proxy ACL operations and
anything else your heart desired to proxy, after adding it to
an FS.
PS: If you wanted to add an fcntl() for directory reading that
could do globbing in the kernel, return only matching entries,
prefault all inodes returned for the inevitable stat(), etc.,
you could achieve a 70% speedup on directory operations for
SAMBA.
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200103140533.WAA03974>