Re: unionfs unusable on multiuser systems (was Re: [PATCH 01/24]Unionfs: Documentation)

[Shaya Potter]

Pavel Machek wrote:
> Hi!
>
> > > > That statement is meant to scare people away from modifying the lower fs :)
> > > > I tortured unionfs quite a bit, and it can oops but it takes some effort.
> > >   But isn't it then potential DOS? If you happen to union two filesystems
> > > and an untrusted user has write access to both original filesystem and
> > > the union, then you say he'd be able to produce oops? That does not
> > > sound very secure to me... And if any secure use of unionfs requires
> > > limitting access to the original trees, then I think it's a good reason
> > > to implement it in unionfs itself. Just my 2 cents.
> > You mean somebody like, say, a perfectly innocent process working on the
> > NFS server or some other client that is oblivious to the existence of
> > unionfs stacks on your particular machine?
> > To me, this has always sounded like a showstopper for using unionfs with
> > a remote filesystem.
>
> Actually, it is worse than that. find / (and updatedb) *will* write to
> all the filesystems (atime).
>
> Expecting sysadmins to know/prevent this seems like expecting quite a
> lot from them. Sounds like a show stopper to me :-(....

a modified atime will not affect unionfs at all (at least from my 
experience)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/