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
[-- Attachment #1 --] 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 kernel and the kernel can't really see the different userland releases. 64-bit call vs 32-bit is ok. > FWIW, I'd prefer to see the dragonfly-ish implementation over > the netbsd-ish implementation. > >> > 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. > > I am extremely uneasy about adding anything related to uid's or > gid's, or similar dynamic values. This argument pops up often without explanation. The only thing I can think of is applications using ".." on a dynamic symlink and ending up 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 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 http://www.feyrer.de/NetBSD/bx/blosxom.cgi/nb_20080714_0251.html . Of 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. > > 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}" ? [-- Attachment #2 --] -----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-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?g8ohbu$a23$1>