Magic symlinks redux

[Ivan Voras]

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}" ?


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20080823/7509f241/signature.pgp