From owner-freebsd-fs Sun Aug 27 8:30:58 2000 Delivered-To: freebsd-fs@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 03DA437B42C; Sun, 27 Aug 2000 08:30:49 -0700 (PDT) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id LAA71933; Sun, 27 Aug 2000 11:30:48 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Sun, 27 Aug 2000 11:30:47 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: phk@FreeBSD.org Cc: freebsd-fs@FreeBSD.org Subject: procfs_lookup() and jail interaction Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Poul-Henning, While propagating changes to process access control, I noticed that I was getting a warning in procfs_vnops.c, in procfs_lookup(). It turned out, I replaced a PRISON_CHECK() with a p_cansee(), and as a macro, PRISON_CHECK didn't have any problem with processing on a "const" struct proc, whereas my p_cansee() does, as it calls suser(). Apparently, the call is made directly on curproc, rather than on the struct proc passed in via cnp, as part of the name lookup. So my first question is: why don't the access control checks in procfs_lookup() relating to jail make use of the struct proc passed in, rather than curproc. My second question has to do with namespace caching. My initial interpretation of this code was that the access control check only happens for the first lookup, and after it's successfully in the name cache, any process can tell that the name exists, even if they can't access it. This occurs because (a) caching access control decisions in the name cache probably doesn't make sense, and (b) our name cache and file system arrangement was not intended to support hidden names in a readable directory. That's not to say we can't hide it in readdir(), just that from the lookup perspective, our vfs just doesn't work that way. Making it work that way would probably be a mistake, as we'd lose many of the performance advantages of our name cache. That said, I'd like to consider what changes should be made in procfs_lookup(). If my glance and understanding are correct: that is, that the lookup protection there is somewhat faulty anyway due to the name cache, should I just eliminate the check? Or alternatively, to clear up the warning, should I make use of a_cnp->curp, which will not be a const struct proc *? Thanks, Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message