--Y5rl02BVI9TCfPar
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Jul 11, 2006 at 04:25:17PM +0200, Pawel Jakub Dawidek wrote:
> On Mon, Jul 10, 2006 at 03:05:26PM -0700, Bill Studenmund wrote:
> > On Mon, Jul 10, 2006 at 10:50:17PM +0200, Pawel Jakub Dawidek wrote:
> > > I think it is acceptable and allows to avoid all those nasty VFS/UFS
> > > hacks.
> >=20
> > What nasty hacks? I've not seen anything that needs to happen at the VF=
S=20
> > layer, and the only thing we might escape at the UFS layer is "you can'=
t=20
> > look up '/.deleted'". Did I miss something?
>=20
> For example I use special VV_DELETED flag to mark an vnode which holds
> such orphaned inode, but this is needed for both cases.

Right, this is needed either way.

> Another thing is that operating on paths is tricky. For example your
> file system is mounted on /foo/bar/baz. You move orphaned objects to
> /foo/bar/baz/.deleted/. How do you handle situation when someone renames
> 'bar' to 'bar2'?

Oh. I begin to see what you mean, and how we've been on very different=20
pages. I now believe you meant "rm -rf .depend/*" far more literally than=
=20
I did. I expected we were speaking figuratively about what fsck was doing=
=20
internally.

> How do you handle situations when process which removed open file is
> chrooted and .deleted/ is no accesable from within his context?

My thought was that ".deleted" is never accessed by paths. It is only=20
accessed/maintained by the file system and fsck when directly accesing the=
=20
disk; VOP_LOOKUP() never returns it. Or it never returns it for accesses=20
that aren't ffs-internal.

Thus your first concern is addressed because we never use a path to get at=
=20
".depend" so it won't matter if paths are renamed.

".deleted" also is a property of the file system, so chrooting doesn't=20
matter. Since files never leave this directory other than to be torn=20
apart, I see no security issue with placing unlinked files from a chrooted=
=20
process there.

> I also needed to introduce special garbage collector thread, which was
> doing removals on last close, because unprivileged processes cannot
> remove objects from .deleted/ directory (it cannot move them there as
> well, by this was handled in a different way).

I am unclear as to why we care about permissions on the ".deleted"
directory. The only access to this directory is performed by the file
system itself, not the file system acting on behalf of some user. So the=20
two types of access (adding a file when unlinked or doing a final delete)=
=20
are always ok.

Take care,

Bill

--Y5rl02BVI9TCfPar
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFEs+b/Wz+3JHUci9cRAvT0AJ9YvCOHtNBbQXftbyWq+flsgHPajACbBQey
MApJaUUWrF4rVMfKfZdYckc=
=fajP
-----END PGP SIGNATURE-----

--Y5rl02BVI9TCfPar--