Date: Fri, 15 Jan 1999 22:23:35 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: robert+freebsd@cyrus.watson.org Cc: Don.Lewis@tsc.tdk.com, eivind@yes.no, fs@FreeBSD.ORG Subject: Re: Mount bogosity Message-ID: <199901152223.PAA13705@usr04.primenet.com> In-Reply-To: <Pine.BSF.3.96.990115084523.25481B-100000@fledge.watson.org> from "Robert Watson" at Jan 15, 99 08:48:19 am
next in thread | previous in thread | raw e-mail | index | archive | help
> Having a 'full path name' for an arbitrary file at a useful time (prior or > after its vnode lookup) would be great for a number of applications > (well, kernel features :) that need to report to the user. This includes > auditing support, where having a name guaranteed unique at the time where > it is used. Also useful, but possibly more prone to pain, would be a > vnode->name facility. > > Posix.1e auditing references filenames in the audit records, hence my > interest at this point. You have to change the way hard links work, and allow proxy vnodes in the kernel as real data structures to allow this. Effectively, a hard link becomes an immediate file, and maintains a linked list of references to the non-hard-link inodes. This is pretty trivially handled by stacking, if stacking works in your kernel (e.g., you have my kernel, or you have BSDI's kernel). Without stacking, it looks like a job for one of Matt Dillon's VM object aliases, but stacking is probably a better way to handle it. The point of the alias is to allow a struct file reference to a vnode to be used to identify that vnode's immediate parent. This works because the vnode in core is a pointer to the real file vnode (i.e., exactly a stacked reference), but is itself a link vonde, and therefore is capable of rememebring the lookup parent inode_t and dev_t, instead of merely being a reference directly to the real vnode's inode_t and dev_t. The end result is that you have a backlink to the parent directory, and since directories implicitly have backlinks, the missing piece is files, and traversal is to root. Given the fact that forward traversal path is always relative to a directory in the first place (as a required argument to VOP_LOOKUP), you don't even have to change the on disk structure; you can, in fact, rememebr parent paths this way on any FS for which hard directory links are not allowed. For hard directory link supporting FS's (there used to be no "rename" system call, so a rename was effected via a non-atomic link, adjust "..", unlink), you would have to have an on disk reference structure to maintain the real parent pointer, since a hard link could make it N-1 deep (for N hops to root from the current directory). Pretty trivial, actually. I implemented this for NWFS in 1993 or so, back when I was at USL (Novell/USG). 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-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199901152223.PAA13705>