Date: Fri, 28 Feb 1997 17:32:20 -0600 (CST) From: Dan Walters <hannibal@cyberstation.net> To: freebsd-fs@freebsd.org Subject: How to get the parent directory vnode of a vnode? Message-ID: <Pine.BSI.3.95.970228164344.3914A-100000@citrine.cyberstation.net>
next in thread | raw e-mail | index | archive | help
I'm starting on an attempt to implement an ACL filesystem layer, mostly
using some ideas from a message I found of Terry Lambert's back in
December (part of it is below my sig). So far I've got the bytestuffing
for the filenames done, the necessary changes in VOP_READDIR to
un-bytestuff the filenames and hide the actual ACL files, and a decent
start on the userland utility... Not much, but it's my first time
touching the kernel...
Anyway, I'm now trying to have it read the actual ACL file into a buffer
in the layer's per-vnode structure. I just noticed, however, that there
is no reference to the parent directory's vnode in a vnode structure, so
I'm having some difficulty deciding on the proper way to lookup the vnode
for the ACL file (which is kept in the same directory). There is mention
of putting the parent directory inode in the ufs layer, but I'm figuring
this would probably not work with NFS, multiple layers, etc.? If I just
trap VOP_LOOKUP, VOP_CREATE, and save the parent directory for each vnode
at that point, would there ever be any case where I wouldn't have a parent
directory vnode?
Also, I want to make sure nobody else is working on something like this.
:) I'd also like to get ahold of the VOP_*.9 manpages that I see mention
of in the list archives - I can't locate them on freefall. I broke down
and bought the 4.4BSD book, but it doesn't really go to the level of depth
I was expecting on much anything.
Thanks!
======================================================================
Dan Walters
hannibal@cyberstation.net
======================================================================
1) Modify the VOP_ADVLOCK to be veto-based
2) Modify the VOP_LOCK code to be veto based. Call a top level
vn_lock to call the underlying VOP_LOCK. Move the vclean
locking to the top level code.
Now NULLFS will no longer crash. If you have a 2.1.5 kernel, take my
patches from -current in June of 1995; they contain this fix.
Using NULLFS, prototype an FS layer that sits on top of an FS using the
following user name space intrusions:
1) If a file name starts with #<digit>, byte-stuff it to ##<digit>
2) Use all #<digit>... file names as names associated with a base
inode number
3) Add in the stacking layer a VOP_IOCTL operation for ACL's.
4) Add subfunctions for "create/delete/add/delete/get" ACL.
5) Write a user space utility to manipulate ACL's.
6) For a file in the directory named "foo", with inode "1745",
the ACL file will be named "#1745".
7) Store all ACL's in the appropriate file. I recommend a sparse
file.
8) Modify the VOP's which take names and call the common lookup
code to enforce your ACL's.
9) remount the FS using the new NULL-derived ACL layer onto the
same mount point. When backing up, unmount the ACL layer
so the backup utility can see the ACL containers as files in the
underlying FS.
10) If you support reverse inheritance, modify the UFS create to
store the parent directory inode in the underlying inode. Add
an option to fsck (during pass 7) to set these for the first
time you start using the new UFS code.
You now have *real* ACL's.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSI.3.95.970228164344.3914A-100000>