Jail FS questions.
kris at obsecurity.org
Thu Oct 9 21:24:53 PDT 2003
On Fri, Oct 10, 2003 at 12:48:49AM -0300, Marc G. Fournier wrote:
> On Thu, 9 Oct 2003, Kris Kennaway wrote:
> > On Thu, Oct 09, 2003 at 10:19:46PM -0300, Marc G. Fournier wrote:
> > > > If I use unionfs as the ``base'' for the jail then every directory seems
> > > > to be automagically owned by the person that mounted it (i.e. root).
> > > > This causes me problems for stuff like mailspool, etc. I think this is
> > > > the way unionfs works though, not an issue I am personally having.
> > >
> > > Ah, neat ... I'd never noticed that before ... its never affected anything
> > > as far as I've experienced though, but we don't unionfs mount /var, as
> > > there is a bug in unionfs dealing with sockets that mounting /var causing
> > > the server to crash repeatedly ...
> > See..that's just what I'm talking about. Software that "works fine as
> > long as you remember not to do X, Y or Z, which will crash the system"
> > is what is called "not production quality". Advocating that users
> > (which are not the same as testers, or developers) use it anyway on
> > their production systems is irresponsible.
> Shooting down ppl that are willing to test and report bugs is equally as
> irresponsible though, and I've been seeing alot of that ...
Okay, so you're changing the topic (we were talking about users, not
> I don't remember whom it was that did it, but I remember a bunch of
> PRs closed recently with the 'big scary warning' as the excuse for
> ignoring the PRs ... the bugs that the reports revolved around
> haven't gone away, but someon felt taht since ppl are warned against
> using it, that those that do shouldn't be filling up GNaTs with PRs
> about it ...
You acknowledge that you are aware of the opinion of a lot of the
developers that many of the bugs in unionfs are systemic and are
impossible to fix without a rewrite of much of the kernel.
There just isn't a lot of value in having GNATS full of reports of
impossible-to-fix bugs in known-buggy software. People who report
such bugs often need to be reminded of the realities: firstly, that
what they have run into is the documented, expected behaviour; and
secondly that they should not expect it to be fixed any time soon.
The appropriate solution is to suspend the PR with a note to this
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20031009/04a3c56d/attachment-0001.bin
More information about the freebsd-questions