lkml.org 
[lkml]   [2017]   [May]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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...

\
 
 \ /
  Last update: 2017-05-05 03:07    [W:0.133 / U:0.032 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site