Thread (13 messages) flat view 13 messages, 6 authors, 2014-11-05

Re: [PATCH 1/3] fs: add O_BENEATH flag to openat(2)

From: David Drysdale <hidden>
Date: 2014-11-03 17:38:01
Also in: lkml

On Mon, Nov 3, 2014 at 3:42 PM, Andy Lutomirski [off-list ref] wrote:
On Mon, Nov 3, 2014 at 7:20 AM, Al Viro [off-list ref] wrote:
quoted
On Mon, Nov 03, 2014 at 11:48:23AM +0000, David Drysdale wrote:
quoted
Add a new O_BENEATH flag for openat(2) which restricts the
provided path, rejecting (with -EACCES) paths that are not beneath
the provided dfd.  In particular, reject:
 - paths that contain .. components
 - paths that begin with /
 - symlinks that have paths as above.
Yecch...  The degree of usefulness aside (and I'm not convinced that it
is non-zero),
This is extremely useful in conjunction with seccomp.
Yes, that was my understanding of how the Chrome[OS] folk wanted
to use it.
quoted
WTF pass one bit out of nameidata->flags in a separate argument?
I'll shift to using nd->flags; not sure what I was thinking of there.

(It *might* have made more sense in the full patchset this was extracted
from but it certainly doesn't look sensible in this narrower context.)
quoted
Through the mutual recursion, no less...  And then you are not even attempting
to detect symlinks that are not followed by interpretation of _any_ pathname.
How many symlinks like that are there?  Is there anything except
nd_jump_link users?  All of those are in /proc.  Arguably O_BENEATH
should prevent traversal of all of those links.

--Andy
On a quick search, the 2 users of nd_jump_link (namely proc_pid_follow_link
and proc_ns_follow_link) seem to be the only implementations of
inode_operations->follow_link that don't just call nd_set_link().  So
disallowing that for O_BENEATH might give sensible behaviour.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help