David Schultz wrote: > Thus spake Pawel Jakub Dawidek <[EMAIL PROTECTED]>: > I'm not sure what you mean by ``temporary names''. Do you mean > that your policy specification permits wildcards in any pathname > component? In that case, you might have to hack the lookup > routines to point to all the possible rule matches as you iterate > down the pathname, so by the time you have a vnode, you also know > what rules match. Scary.
It will work, but he will have to implement mandatory locking for directory entries (minimally), if he insists on doing it by name, rather than by dev_t/ino_t pair. Realize that it's actually trivial to do dev_t/ino_t/dev_t/ino_t for "inode in directory". FreeBSD does not permit hard links on directories, and directories already cache parent directories, as their ".." entry. So you can (effectively) implement absolute pathing, as long as inherited rights deal *only* with the directories, and not with the files themselves (unlike NetWare). But mandatory locking for the terminal directory entry is still a requirement, since otherwise, you can still create/open/unlink...close, and before the close, you can subvert any by-name MACs you try to apply. > Keep in mind that if you're willing to bite the performance > bullet, you may be able to implement a userland solution far > more easily. > > http://www.cs.berkeley.edu/~daw/janus/ This is a good reference. If this is just a student project, and not a commercial product, doing the work in user space is probably the way to go. If it's supposed to be commercial, I don't see any way around at least minimally modifying the FS. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
