Re: [PATCH] new syscall: flink

[torvalds@transmeta.com (Linus Torvalds)]

In article <3E90746A.2010300@redhat.com>,
Ulrich Drepper  <drepper@redhat.com> wrote:
>
>I got a couple of requests for a function which isn't support on Linux
>so far.  Also not supportable, i.e., cannot be emulated at userlevel.
>It has some history in other systems (QNX I think), though, and helps
>with some security issues.  It really not adding much new functionality
>and I hope I got it right with my "monkey see, monkey do" technique of
>looking up other places doing similar things.

As others have pointed out, there is no way in HELL we can do this
securely without major other incursions.

In particular, both flink() and funlink() require that you do all the
same permission checks that a real link() or unlink() would do. And as
some of them are done on the _source_ of the file, that implies that
they have to be done at open() time.

One check in particular is "is the opener willing to let this be linked
anywhere else in the namespace". Since the opener isn't necessarily the
same agent as the one doing the flink().

If you really really think you need this (and not just do it because
some random idiot-customer doesn't understand security), then I would
suggest you add a O_CANLINK flag to open, and require that that flag is
set in the file descriptor.

That way you get "flink()" behaviour, but you require that the opener be
aware of the fact that the file may be linked into another position.
That will fix the glaring security hole.

		Linus