Messages in this thread | | | Date | Fri, 5 May 2017 02:06:54 +0100 | From | Al Viro <> | Subject | Re: new ...at() flag: AT_NO_JUMPS |
| |
On Thu, May 04, 2017 at 05:44:19PM -0700, Andy Lutomirski wrote: > > It's not quite O_BENEATH, and IMO it's saner that way - a/b/c/../d is > > bloody well allowed, and so are relative symlinks that do not lead out of > > the subtree. If somebody has a good argument in favour of flat-out > > ban on .. (_other_ than "other guys do it that way, and it doesn't need > > to make sense 'cuz security!!1!!!", please), I'd be glad to hear it. > > I don't have an argument for allowing '..'. I think it would be okay > to disallow it, but I don't think it matters all that much either way.
Relative symlinks as argument in favour of allowing .. _when_ _it_ _stays_ _in_ _subtree_.
> > For the latter I would prefer -EXDEV, for obvious reasons. For the former... > > not sure. I'm not too happy about -ELOOP, but -EPERM (as with O_BENEATH) > > is an atrocity - it's even more overloaded. > > > > Suggestions? > > -EDOTDOT would be amusing.
For ln -s /tmp foo/bar, lookup for foo/bar/baz? Seriously? Hell, even -EXDEV would make more sense...
| |