Darren J Moffat wrote:
> Alan.M.Wright wrote:
>> We are reserving '@{...}', i.e. the name must start with @{ and end
>> with }.
>>
>> We considered both a global option and per file system options but, on
>> the basis that no-one could identify a scenario in which something would
>> misinterpret these objects and behave badly, we decided not to propose
>> an enable/disable switch.
>
> So that fact that you can today create a symlink pointing to such a file
> isn't a case of behaving badly ?
>
> estale:pts/83$ echo "hello world" > "@{REPARSE:NFS:00000}"
> estale:pts/83$ ln -s @\{REPARSE:NFS:00000\} @\{REPARSE:NFS:00001\}
> estale:pts/83$ ls -l
> total 2
> -rw-r--r-- 1 darrenm staff 12 Jul 14 12:03 @{REPARSE:NFS:00000}
> lrwxrwxrwx 1 darrenm staff 20 Jul 14 12:04
> @{REPARSE:NFS:00001} -> @{REPARSE:NFS:00000}
(I don't think that's quite the right syntax, but that's not important.)
Is it true that any old user can create symlinks whose content will be
interpreted as a reparse point? If so, what protections are in place to
prevent arbitrary content in such a user-created symlink from tricking
the system into doing something bad? Presumably the protection would be
implemented in 'reparsed' or its plug-ins, which aren't described in
this case, but perhaps you can comment on the general approach that will
be used to defend against abuse of the service data in the symlink
content.
Mike.
--
mike.oliver at sun.com
> estale:pts/83$ cat @\{REPARSE:NFS:00000\}
> hello world
> estale:pts/83$ cat @\{REPARSE:NFS:00001\}
> hello world
>
> Just because you don't create files beginning @{ and ending } doesn't
> mean they don't exist. Given all the rest of the data that has to be in
> there I think the changes are very very slim. The issue isn't so much
> with the REPARSE but the reserving of all @{...} which this case claims
> to do. Again I think the chances of a problem are slim but there must
> be a reason why BSD made this optional, no ?
>
> Note I'm no longer arguing against the case I'm just recording the fact
> that there is a risk in reserving this symlink content namespace though
> it is a very small one.
>
> Given everything I've said and the discussion that has been had I'm now
> okay supporting this case and give it my @{PSARC:+1}.
>
