From owner-freebsd-hackers Mon Jan 6 16:22:12 2003 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6407337B401 for ; Mon, 6 Jan 2003 16:22:11 -0800 (PST) Received: from HAL9000.homeunix.com (12-233-57-224.client.attbi.com [12.233.57.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0C44C43EB2 for ; Mon, 6 Jan 2003 16:22:10 -0800 (PST) (envelope-from dschultz@uclink.Berkeley.EDU) Received: from HAL9000.homeunix.com (localhost [127.0.0.1]) by HAL9000.homeunix.com (8.12.6/8.12.5) with ESMTP id h070M5PN000773; Mon, 6 Jan 2003 16:22:05 -0800 (PST) (envelope-from dschultz@uclink.Berkeley.EDU) Received: (from das@localhost) by HAL9000.homeunix.com (8.12.6/8.12.5/Submit) id h070M5po000772; Mon, 6 Jan 2003 16:22:05 -0800 (PST) (envelope-from dschultz@uclink.Berkeley.EDU) Date: Mon, 6 Jan 2003 16:22:05 -0800 From: David Schultz To: Pawel Jakub Dawidek Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Caching [sugestion]. Message-ID: <20030107002205.GA655@HAL9000.homeunix.com> Mail-Followup-To: Pawel Jakub Dawidek , freebsd-hackers@FreeBSD.ORG References: <20030105215024.GB99855@prioris.mini.pw.edu.pl> <3E18B97A.32ABAE7@mindspring.com> <20030106074005.GB6825@prioris.mini.pw.edu.pl> <20030106163723.GA721@HAL9000.homeunix.com> <20030106233427.GC6825@prioris.mini.pw.edu.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030106233427.GC6825@prioris.mini.pw.edu.pl> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Thus spake Pawel Jakub Dawidek : > +> It sounds like you're trying to do something complicated with > +> chdir, and that could make things harder. First of all, you > +> should be comparing vnodes instead of pathnames when possible, in > +> order to avoid canonicalization bugs. Second, it only makes sense > +> to ask for the path of a directory vnode, since ordinary files can > +> have multiple hard links. For directories, you can get the full > +> path by walking up the '..' pointers, sort of like vn_fullpath(), > +> except that you have to do a lookup if something is missing from > +> the cache. I expect locking would be a pain as well. > > Yes, I know that already. Soon I'll send announce of what I'm doing, > for now I'll use my ugly way. > > Not always is chance to operate only on vnodes. When You (for example) > want to denied mode changes for some file, You can do this through catching > chmod(2), but when someone open this file how You get file name when You want > create policy rules for fchmod(2)? Remember that files could have temporary > names, so You can't compare vnode from file descriptor with some file that > You're expecting. I'm telling you, you almost certainly will run into canonicalization problems unless you compare the vnodes, rather than the paths. Can't you just namei the paths in your policy rules and use the resulting vnodes to match relevant system calls? 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. 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/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message