Messages in this thread | | | From | (Linus Torvalds) | Subject | Re: [PATCH] new syscall: flink | Date | Mon, 7 Apr 2003 17:35:16 +0000 (UTC) |
| |
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |