re: [PATCH] new syscall: flink

[Dan Kegel <dank@kegel.com>]

Ulrich 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.

How does this differ from fattach() in SuSv3
(http://www.opengroup.org/onlinepubs/007904975/functions/fattach.html)?
(i.e. does the fact that fattach() is defined only for streams
fds make a difference?)

Out of curiosity, I did some searching for prior mentions of flink.
It gets proposed every two years or so, it seems.
There may be some security issues.  Here are two posts that
might be of interest (I wouldn't know, I'm not a security guru):

http://marc.theaimsgroup.com/?l=linux-kernel&m=88944672732020&w=2
Malcolm Beattie <mbeattie () sable ! ox ! ac ! uk> wrote:
> SysV calls this fattach() where fd is a STREAMS file descriptor
> (usually a STREAMS pipe). For general file descriptors, it has
> security implications. For example, you mustn't let it be legal
> for a process to get a read-only file descriptor and then link
> it into the file system because then it could change the file's
> permissions to read-write.

http://mail-index.netbsd.org/tech-userlevel/2001/09/29/0000.html
Andrew Brown <atatat@atatdot.net> wrote:
 ># as for flink(2), no.  flink(2) would be a terribly bad idea.  consider
 ># that when opening a file, *all* the permissions on *all* the inodes in
 ># the path to the file are considered.  if you were able to get some
 ># process to hand you an open file descriptor to some file somewhere
 ># that relies on being protected by permissions in the path and you were
 ># able to flink(2) it to some arbitrary name, you could bypass the
 ># permissions set that had been established.

- Dan

-- 
Dan Kegel
http://www.kegel.com
http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045