Magic symlinks redux

[Ivan Voras]

Brooks Davis wrote:
> On Fri, Aug 22, 2008 at 05:53:58PM +0200, Ivan Voras wrote:

>> 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.
> 
>> Anyway, if the DFBSD framework is properly implemented, it shouldn't
>> be hard to add these variables. If you don't want to, I volunteer.
> 
> I'm not completely opposed to adding a static namespace for system
> wide variables.  I'm not at all keen on the @ruid and @uid variables
> because I think they are risky.  My current feeling is that I'd like to
> move ahead with my current implementation and then either add another
> namespace or add this off to the side mostly as is.

Ok, how about adding another sysctl enabling ruid and uid (perhaps 
change their name to uid and euid since NetBSD compatibility isn't 
maintained) which will be off by default?

>> (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%%.  

Someone mentioned "@" clashes with AFS :(

 > I don't like the unanchored components netbsd uses.

They could have an use case - see below:

> One other option we discussed at the devsummit was requiring that the first
> character of a variant symlink be special to reduce parsing overhead.  I.e.
> requiring that variant symlinks start with @ or % or something.

I agree with this - it's elegant on the implementation side and 
performance hit would be minimal. I'd also be happy with abandoning the 
free form links and mandating that the entire component be one var 
symlink (i.e. "/path1/@var/path2" is ok but "/path1/@{path2}.@{path3}" 
isn't).

If you'd implement that special starting character, how would the 
end-result look like? Something like "#path@{var}"? (for various values 
of "#")?

-------------- 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/9daad309/signature.pgp