Date: Sat, 23 Aug 2008 10:22:19 +0200 From: Ivan Voras <ivoras@freebsd.org> To: freebsd-arch@freebsd.org Subject: Re: Magic symlinks redux Message-ID: <g8ohbu$a23$1@ger.gmane.org> In-Reply-To: <p0624080ec4d51f26d476@[128.113.24.47]> References: <g8kv7v$sp2$1@ger.gmane.org> <20080822150020.GA57443@lor.one-eyed-alien.net> <9bbcef730808220802pa84b597u457100a23b03a80c@mail.gmail.com> <20080822153945.GC57443@lor.one-eyed-alien.net> <9bbcef730808220853q22666b44n5ca2b7add991191f@mail.gmail.com> <20080822161314.GE57443@lor.one-eyed-alien.net> <p0624080ec4d51f26d476@[128.113.24.47]>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD9B0C8D32B67DA3D530210C6 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Garance A Drosehn wrote: > I like the idea of having some of these mostly-static values, > although (as you note), we should to think about how these might > be effected within jails. I have jails (really chroot areas) > which have different @osreleases than the running kernel, for > instance. This last case would be problematic since symlinks are resolved in=20 kernel and the kernel can't really see the different userland releases.=20 64-bit call vs 32-bit is ok. > FWIW, I'd prefer to see the dragonfly-ish implementation over > the netbsd-ish implementation. >=20 >> > Your example with uid is solved just like in userland (though >> > the names are messed up) and reflect getuid() and geteuid(). >> >> Small changes to the file system namespace can easily lead to security= >> issues when applications assume the namespace is static. This is >> particularly true for setuid binaries. >=20 > I am extremely uneasy about adding anything related to uid's or > gid's, or similar dynamic values.=20 This argument pops up often without explanation. The only thing I can=20 think of is applications using ".." on a dynamic symlink and ending up=20 somewhere where it doesn't want to, but this can also be said for normal = symlinks. Can anyone explain more possible security problems with having @uid in=20 varsymlinks? > I can't help but think tbat > any case where this would be useful, it would also be very risky > with-respect-to setuid() binaries. I posted a nice use-case at the first post: per-user /tmp like in=20 http://www.feyrer.de/NetBSD/bx/blosxom.cgi/nb_20080714_0251.html . Of=20 course it's a "nice to have", not a critical feature. >> > (I don't care about the syntax: @{something} vs ${something}, >> > though I think NetBSD made the better choice since these >> > variables are not accessing the process environment). >> >> This is something I've been debating. I've been leading toward >> something other than ${something}. Either @{} or %{} or else >> going all the way to something like %%something%%. I don't like >> the unanchored components netbsd uses. >=20 > This could easily degenerate into a bikeshed issue, but let me > at least say that I think we should avoid "@varname". That's > the syntax which AFS/OpenAFS/ARLA uses for their equivalent of > variant filename paths, and I think it would be good if we avoid > any confusion with that. How about "@{varname}" ? --------------enigD9B0C8D32B67DA3D530210C6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIr8i7ldnAQVacBcgRAkopAJ9blmSklcKUKFGfC87DgSdmBt4kNwCgsawj QTLS4s+KkFWkw1PWL17zDc0= =6bf8 -----END PGP SIGNATURE----- --------------enigD9B0C8D32B67DA3D530210C6--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?g8ohbu$a23$1>