|Subject:||procfs_lookup() and jail interaction|
|From:||Robert Watson (rwat...@FreeBSD.org)|
|Date:||Aug 27, 2000 8:30:25 am|
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 *?
Robert N M Watson
To Unsubscribe: send mail to majo...@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message