In article <fb7ddfab3b.fab3bfb7dd@teleline.es>,
RAMON_GARCIA_F <RAMON_GARCIA_F@terra.es> wrote:
>I suggest to add a new system call for transfering a file handle between
>two processes.
>
>In Linux, transfer of file handles can be done through a Unix domain
>socket. This mechanism is quite unflexible. It requires that the two
>applications connect by this kind of socket, and it is difficult to
>use from shell scripts.
Why, write a small program 'passfd /var/run/socket fd1 fd2' which
does the work for you.
>Let cdwritter be a program for writting CDs. Unlike other programs,
>cdwritter is rationally designed. It is a server process that listens
>through a named pipe, thus making it easy to write either command line
>or graphical interfaces that use its functionality. The named pipe
>is called /var/run/cdwritter
>
>An alternative would be that cdwritter accepts a file name instead of
>a cookie. But then, the author of cdwritter would have to check if the
>user has permission to access the file. This makes cdwritter more error
>prone.
You can get the uid/gid on the other side of a unix socket easily,
so you just setfsuid() / open(). But again you do need to use
a Unix socket, not a pipe, so you need a small client program.
There have been patches to the kernel to treat an open() on a
unix socket as a bind() + connect(), but unfortunately that has
never been integrated in mainline.
Now that we have getsockopt(SO_PEERCRED, &ucred) the above would
be very useful.
Mike.
-
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/
This archive was generated by hypermail 2b29 : Wed Jul 23 2003 - 22:00:37 EST