From owner-freebsd-current@FreeBSD.ORG Sun Jun 27 07:23:28 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 39B4B16A4CE; Sun, 27 Jun 2004 07:23:28 +0000 (GMT) Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by mx1.FreeBSD.org (Postfix) with ESMTP id E00A643D1D; Sun, 27 Jun 2004 07:23:27 +0000 (GMT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (sccrmhc13) with ESMTP id <20040627072321016005pfute>; Sun, 27 Jun 2004 07:23:27 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id AAA24225; Sun, 27 Jun 2004 00:23:19 -0700 (PDT) Date: Sun, 27 Jun 2004 00:23:18 -0700 (PDT) From: Julian Elischer To: Pawel Jakub Dawidek In-Reply-To: <20040627065932.GH12007@darkness.comp.waw.pl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: FreeBSD current users cc: bzeeb+freebsd@zabbadoz.net Subject: Re: jail getfsstat patches. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jun 2004 07:23:28 -0000 On Sun, 27 Jun 2004, Pawel Jakub Dawidek wrote: > On Fri, Jun 25, 2004 at 06:15:41PM -0700, Julian Elischer wrote: > +> There are patches around to make 'df' and 'mount' > +> show pretty much the exact right thing from a jail. > +> > +> In both -current and 4.x > +> > +> I propose to commit these. > +> > +> http://garage.freebsd.pl/ > +> "jailfsstat - With this kernel module process in jail can only see file > +> systems mounted inside." > +> > +> for 4.x > +> > +> and > +> > +> http://sources.zabbadoz.net/freebsd/jail.html > +> for 5.x > +> > +> with possible small changes.. > +> > +> e.g. the 4.x version would not be a module > +> but would have a sysclt to turn it on > +> (off by default) > +> > +> and the 5.x version may require osme small work too.. > +> > +> > +> Does anyone violently object to these? > +> > +> The fact that df or mount shows so much not only confuses the hell > +> out of users, it makes scripts fail in odd ways. > +> (and bugs the hell out of me too). > > We have talked with rwatson a lot about this (in the past and currently) > and this is really non-trivial work if we want to do it as it should be > done. > > First of all we depend on fact, that mount(8) gives full path to mount(2) > (without any symlinks, .., ., etc.). If mount(2) will be called with > relative path, we're in trouble. > To fix this we need to do realpath(3) in kernel, in mount(2) syscall. > We don't have such function in kernel atm. I wrote one for cerb, > but this code was quite complex and I don't know if we want to bring it in. > > There are many situations when we can't just depend on f_mntonname field, > because path there could not be valid (e.g. when root will rename one of > those path's components). Of course it is not good thing to do anyway, > but in this situation it brings us in bigger trouble. > > The best way to do it is to walk up from the vnode where file system is > mounted on to the vnode where jail's root directory starts. But I think > this is not possible with our VFS. > > Anyway. > > I know that it will be a good thing to do something with it, even if we > cannot use a perfect solution. > > IMHO we shouldn't use Bjoern's patch, it is ok, but for base system it is > too complex (I found at least one bug, in line 455 in file HEAD-20040606.diff) > and I think simple sysctl to turn it on and off is enough for us and will > simplify code a lot. Bjoern, are you ok with this? > > If you give me a few days (maybe I'll be ready today) I'll try to prepare > patch to commit so we can review it together. I really just want something that covers the simple cases. matching and removing the string that was used to define the jail is enough. In fact the module for 4.x is enough for me at the moment but I'd rather see it built in than to have to keep a separate module in sync. (and then have to go through it all again when we go to 5.x). > > -- > Pawel Jakub Dawidek http://www.FreeBSD.org > pjd@FreeBSD.org http://garage.freebsd.pl > FreeBSD committer Am I Evil? Yes, I Am! >