Hello.
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.
The new mechanims proposed is more flexible.
A cookie is a large integer number (160 bit suggested) that can be used
to refer to a file handle from any process. It is randomly choosen by
the kernel at creation time. Afterwards, any process that knows this
cookie can convert it back to a file handle. When this conversion is
done, the cookie dies and is no longer valid.
An example of why cookies are useful.
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
To keep this discussion simple, cdwritter supports writting a single
file (usually an ISO image) to a cdrecorder. The user gives a command,
and afterwards the CD is burned. To write a file, the user must write a
string "write <cookie>" to /var/run/cdwritter. The cookie is used to
identify the file.
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.
Shell scripts can write CDs to cdwriter. The command get_cookie, opens a
file given on the command line and prints a cookie on stdout. Thus a
shell script for burning the image my_nude_photos.iso would be:
echo "write $(get_cookie my_nude_photos.iso)" > /var/run/cdwritter
CREDITS: The Plan9 operating system provided inspiration for this idea.
Ramon
Hi Ramon,
On Thu, Jul 17, 2003 at 07:47:11PM +0200, RAMON_GARCIA_F wrote:
> 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
Calling this tool simply with an argument (eg. CD to write) and
accepting commands from stdin, outputting status info on stdout
and errors on stderr is even simpler and requires no API changes ;-)
> 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.
With my suggested change this is done implicitly.
But with that cookie suggestion in place, to remove the ability
for fds to be reference countable, since the user can build
circular dependencies now, which he for now can just do with
AF_UNIX sockets.
Regards
Ingo Oeser
Do unix(7) sockets with cmsg(UCM_RIGHTS) not give you what you want?
You can have a cookie process sitting in user space waiting on a UNIX
socket. When somebody passes you the right cookie string, you send them
a file descriptor.
mark
P.S. I had to look a bit for cmsg(UCM_RIGHTS). I was more familiar with
ioctl(I_SENDFD), which it appears that Linux does not implement.
--
[email protected]/[email protected]/[email protected] __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada
One ring to rule them all, one ring to find them, one ring to bring them all
and in the darkness bind them...
http://mark.mielke.cc/
In article <[email protected]>,
RAMON_GARCIA_F <[email protected]> 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.
Although it is posible to use unix sockets, my proposal
integrates better with shell scripts.
Ramon
On Mon, Jul 21, 2003 at 11:49:15AM +0200, RAMON_GARCIA_F wrote:
> Although it is posible to use unix sockets, my proposal
> integrates better with shell scripts.
How?
Whether you put magic into the kernel, or you build a user space server,
the interface can be the exact same. I don't buy the 'integrates better'
argument.
It looks like you want simpler code in user space, at the cost of
complicating the kernel, for a feature that will be not be used very
frequently at all. Is this not correct?
mark
--
[email protected]/[email protected]/[email protected] __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada
One ring to rule them all, one ring to find them, one ring to bring them all
and in the darkness bind them...
http://mark.mielke.cc/
RAMON_GARCIA_F <[email protected]> said:
> Although it is posible to use unix sockets, my proposal
> integrates better with shell scripts.
I fail to see why using sockets et al in shell scripts is that important.
You have full access to the API from Perl, for one; shell scripts are used
mostly as scaffolding for calling "normal" programs, so inventing something
to do what you want and call that from the shell is the way to go IMHO.
Only if there is absolutely no way to do it sanely outside the kernel, and
futhermore it is very important to do, should the kernel get involved
(sure, Linux is way the largest Unix installed base around today, but still
_far_ from the one that defines the standards in the area, which means a
Linux-only system call is a step forward and three back, so...)
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
My proposal is useful for cases where the server program is running with
a different priviledge from the user invoking it. Examples where this
behaviour is useful are writting CDs, saving man pages, saving TeX cache
files, where full access to a resource would be unsafe, but limited
access through an intermediate server is safe.
In addition, this proposal is useful for cases where the server process
cannot access the named file, becaue it does not have permission to do
so, or because it is anonymous (example: a pipe).
I can't see why cookies introduce circular references. A cookie referes
to an inode, but an inode does not refer to a file.
However, a cookie introduces a permanent reference to a file handle.
This reference is not destroyed until the cookie is used. Therefore,
cookies should have a timeout associated with them, so that if they
are not consumed they should be destroyed.
Ramon
What part of this cannot be implemented from user space using unix sockets?
Consider that an implementing using a user space daemon and unix sockets
would be portable to any system that implemented either ioctl(I_SENDFD)
or cmsg(SCM_CREDENTIALS). The former should function properly on all
operating systems that fully implements streamio support, such as Solaris
and HP-UX.
Your proposed solution unnecessary complicates the kernel, and ensures
that the feature cannot be used on any other platform except Linux, and
even then, only versions of Linux that include your patch.
Why restrict yourself like this?
mark
On Mon, Jul 21, 2003 at 06:55:24PM +0200, RAMON_GARCIA_F wrote:
> My proposal is useful for cases where the server program is running with
> a different priviledge from the user invoking it. Examples where this
> behaviour is useful are writting CDs, saving man pages, saving TeX cache
> files, where full access to a resource would be unsafe, but limited
> access through an intermediate server is safe.
>
> In addition, this proposal is useful for cases where the server process
> cannot access the named file, becaue it does not have permission to do
> so, or because it is anonymous (example: a pipe).
>
> I can't see why cookies introduce circular references. A cookie referes
> to an inode, but an inode does not refer to a file.
>
> However, a cookie introduces a permanent reference to a file handle.
> This reference is not destroyed until the cookie is used. Therefore,
> cookies should have a timeout associated with them, so that if they
> are not consumed they should be destroyed.
>
> Ramon
>
>
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
[email protected]/[email protected]/[email protected] __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada
One ring to rule them all, one ring to find them, one ring to bring them all
and in the darkness bind them...
http://mark.mielke.cc/
It might be posible to implement in user space. I have not fully studied
it to see if there are significant problems.
I believe that innovation is a public good that should be actively
promoted. Otherwise technology would never advance.
The complication added to the kernel is minimal because the primitive is
simple. That is actually the most important reason why I like it.
There are barriers to adopting, such as portability. But if the
primitive is included in standard Linux and is found useful by
application developers, other Unixes will follow.
Ramon
On Mon, Jul 21, 2003 at 09:48:49PM +0200, RAMON_GARCIA_F wrote:
> I believe that innovation is a public good that should be actively
> promoted. Otherwise technology would never advance.
Innovation quite often means working with what you have.
mark
--
[email protected]/[email protected]/[email protected] __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada
One ring to rule them all, one ring to find them, one ring to bring them all
and in the darkness bind them...
http://mark.mielke.cc/