Re: [PATCH 01/11] fs: add O_BENEATH_ONLY flag to openat(2)

Re: [PATCH 01/11] fs: add O_BENEATH_ONLY flag to openat(2)

[Christoph Hellwig]

On Mon, Jun 30, 2014 at 08:53:01AM -0700, Andy Lutomirski wrote:
> > Wouldn't it need to be both O_BENEATH_ONLY (for openat()) and
> > AT_BENEATH_ONLY (for other *at() functions), like O_NOFOLLOW and
> > AT_SYMLINK_NOFOLLOW?  (I.e. aren't the AT_* flags in a different
> > numbering space than O_* flags?)
> >
> > Or am I misunderstanding?
> >
> 
> Ugh, you're probably right.  I wish openat had separate flags and
> atflags arguments.  Oh well.

There's two different AT_* namespaces.  The flags that most *at syscalls
has, and the the one for the dfd argument, which currently only contains
AT_FDCWD, although a new constant has recently been proposed to it.

Having an AT_BENEATH magic value for the dfd argument certainly feels
elegant to me, but seems to be against the language for openat in Posix:

"The openat() function shall be equivalent to the open() function except
in the case where path specifies a relative path. In this case the file
to be opened is determined relative to the directory associated with the
file descriptor fd instead of the current working directory. If the file
descriptor was opened without O_SEARCH, the function shall check whether
directory searches are permitted using the current permissions of the
directory underlying the file descriptor. If the file descriptor was
opened with O_SEARCH, the function shall not perform the check.

The oflag parameter and the optional fourth parameter correspond exactly
to the parameters of open().

If openat() is passed the special value AT_FDCWD in the fd parameter,
the current working directory shall be used and the behavior shall be
identical to a call to open()."

Re: [PATCH 01/11] fs: add O_BENEATH_ONLY flag to openat(2)

[Meredydd Luff]

On 8 July 2014 13:07, Christoph Hellwig <hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org> wrote:
> There's two different AT_* namespaces.  The flags that most *at syscalls
> has, and the the one for the dfd argument, which currently only contains
> AT_FDCWD, although a new constant has recently been proposed to it.
>
> Having an AT_BENEATH magic value for the dfd argument certainly feels
> elegant to me

How would that work? The directory beneath which openat is looking is
conveyed in the dfd argument itself. If I'm understanding this right,
you'd have to pass a different value for "open relative to fd#5" and
"open relative to fd#5, but beneath it only", which doesn't sound
hugely elegant to me.

Meredydd

Re: [PATCH 01/11] fs: add O_BENEATH_ONLY flag to openat(2)

[Christoph Hellwig]

On Tue, Jul 08, 2014 at 01:48:27PM +0100, Meredydd Luff wrote:
> How would that work? The directory beneath which openat is looking is
> conveyed in the dfd argument itself. If I'm understanding this right,
> you'd have to pass a different value for "open relative to fd#5" and
> "open relative to fd#5, but beneath it only", which doesn't sound
> hugely elegant to me.

Yeah, it won't work for an explicit directory - I was thinking of
working relative to $CWD.

Re: [PATCH 01/11] fs: add O_BENEATH_ONLY flag to openat(2)

[Meredydd Luff]

On 8 July 2014 13:51, Christoph Hellwig <hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org> wrote:
> Yeah, it won't work for an explicit directory - I was thinking of
> working relative to $CWD.

I think that would sacrifice far too much flexibility. Even without
Capsicum, it would be worthwhile to be able to wire up a static
seccomp-bpf filter to enforce constraints such as "you can open files
under fd#5 for reading, but you can only write to files under fd#6,
and you can't do any global lookups."

Meredydd
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 01/11] fs: add O_BENEATH_ONLY flag to openat(2)

[Christoph Hellwig]

On Tue, Jul 08, 2014 at 02:04:45PM +0100, Meredydd Luff wrote:
> On 8 July 2014 13:51, Christoph Hellwig <hch@infradead.org> wrote:
> > Yeah, it won't work for an explicit directory - I was thinking of
> > working relative to $CWD.
> 
> I think that would sacrifice far too much flexibility. Even without
> Capsicum, it would be worthwhile to be able to wire up a static
> seccomp-bpf filter to enforce constraints such as "you can open files
> under fd#5 for reading, but you can only write to files under fd#6,
> and you can't do any global lookups."

Yeah, I didn't intend to advocate this further after your reply.