From: Edgar Toernig <froese@gmx.de>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Pekka Enberg <penberg@cs.helsinki.fi>,
Pavel Machek <pavel@ucw.cz>,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
akpm@osdl.org, viro@zeniv.linux.org.uk, tytso@mit.edu,
tigran@veritas.com
Subject: Re: [RFC/PATCH] revoke/frevoke system calls V2
Date: Wed, 9 Aug 2006 10:41:55 +0200 [thread overview]
Message-ID: <20060809104155.48ad3c77.froese@gmx.de> (raw)
In-Reply-To: <1155040157.5729.34.camel@localhost.localdomain>
Alan Cox wrote:
>
> Ar Llu, 2006-08-07 am 22:41 +0200, ysgrifennodd Edgar Toernig:
> >
> > Your implementation is much cruder - it simply takes the fd
> > away from the app; any future use gives EBADF. As a bonus,
>
> It needs to give -ENXIO/0 as per BSD that much is clear.
Ah, OK. And not to forget select/poll. (What about SIGHUP?)
I'm not sure though, whether it's really necessary to allow the
owner of a file to revoke fds - I would feel better if only root
(or someone with the right caps) could revoke fds/mappings.
> To use revoke() I must own the file
> If I own the file I can make it a symlink to a pty/tty pair
> I can revoke a pty/tty pair
With the EIO/EOF behaviour that's not a problem - apps that deal
with ttys have to expect that condition.
> > A serious question: What do you need this feature of revoking
> > regular files (or block devices) for? Maybe my imagination
> > is lacking, but I can't find a use where fuser(1) (or similar
> > tools) wouldn't be as good or even better than revoke(2).
>
> On a typical non-SELinux system with a typical desktop configuration
> (SELinux can effectively replace revoke) you need revoke on block
> devices in order to guarantee security
Hmm... which apps have an open fd on block devices? Usually a
filesystem is mounted on the device and then there are no fds
to the block-dev involved. Or do you expect the "fuser -m"
behaviour from revoke? Afaics, that's not the case at the moment.
Which users have perms to access a block-dev anyway?
> There are specific cases where being able to revoke access to one of
> your files is useful as well, particularly if you are moving it from
> open permissions to private permissions. That one is to be honest much
> less interesting and it is easy enough to make our revoke()
> implementation return -EINVAL.
Hmm... then use fuser and kill the process instead of silently taking
away fds and mappings.
My summary: revoke on chars devs with EIO/EOF behaviour is ok.
revoke on blocks devs is questionable
revoke on regular files is wrong.
Ciao, ET.
next prev parent reply other threads:[~2006-08-09 8:42 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-27 14:25 [RFC/PATCH] revoke/frevoke system calls V2 Pekka J Enberg
2006-07-27 15:07 ` Alan Cox
2006-07-27 15:33 ` Pekka Enberg
2006-07-27 16:09 ` Alan Cox
2006-07-27 16:01 ` Pekka J Enberg
2006-07-27 16:30 ` Alan Cox
2006-07-27 17:07 ` Pekka J Enberg
2006-07-27 18:27 ` Pekka Enberg
2006-07-27 16:41 ` Ulrich Drepper
2006-07-27 17:05 ` Pekka J Enberg
2006-07-27 17:13 ` Ulrich Drepper
2006-07-27 17:33 ` H. Peter Anvin
2006-07-27 17:44 ` Ulrich Drepper
2006-07-27 18:00 ` H. Peter Anvin
2006-07-27 17:33 ` Alan Cox
2006-07-27 17:33 ` O_CAREFUL flag to disable open() side effects H. Peter Anvin
2006-07-27 17:43 ` Russell King
2006-07-27 17:50 ` Ulrich Drepper
2006-07-27 18:05 ` Alan Cox
2006-07-27 18:03 ` H. Peter Anvin
2006-08-05 21:05 ` [RFC/PATCH] revoke/frevoke system calls V2 Pavel Machek
2006-07-27 18:06 ` Petr Baudis
2006-07-27 18:10 ` Pekka Enberg
2006-07-27 19:30 ` Horst H. von Brand
2006-07-28 3:40 ` Pekka J Enberg
2006-07-27 18:34 ` Alan Cox
2006-08-05 12:29 ` Pavel Machek
2006-08-07 5:42 ` Pekka J Enberg
2006-08-07 8:17 ` Edgar Toernig
2006-08-07 9:51 ` Pekka Enberg
2006-08-07 20:41 ` Edgar Toernig
2006-08-07 22:24 ` Chase Venters
2006-08-08 12:15 ` Alan Cox
2006-08-09 8:41 ` Edgar Toernig
2006-08-09 10:39 ` Alan Cox
2006-08-09 18:00 ` Edgar Toernig
2006-08-09 18:36 ` Alan Cox
2006-08-09 19:13 ` Pekka Enberg
2006-08-09 20:08 ` Edgar Toernig
2006-08-09 21:29 ` Edgar Toernig
2006-08-11 7:52 ` Helge Hafting
2006-08-08 12:29 ` Alan Cox
2006-08-08 12:31 ` Pekka Enberg
2006-08-08 12:57 ` Pavel Machek
2006-08-08 14:14 ` Alan Cox
2006-08-08 13:57 ` Pavel Machek
2006-08-09 8:41 ` Edgar Toernig [this message]
2006-08-09 10:42 ` Alan Cox
2006-08-09 18:00 ` Edgar Toernig
2006-08-09 18:35 ` Alan Cox
2006-08-09 19:14 ` Pekka Enberg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060809104155.48ad3c77.froese@gmx.de \
--to=froese@gmx.de \
--cc=akpm@osdl.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pavel@ucw.cz \
--cc=penberg@cs.helsinki.fi \
--cc=tigran@veritas.com \
--cc=tytso@mit.edu \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).