[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20060809104155.48ad3c77.froese@gmx.de>
Date: Wed, 9 Aug 2006 10:41:55 +0200
From: Edgar Toernig <froese@....de>
To: Alan Cox <alan@...rguk.ukuu.org.uk>
Cc: Pekka Enberg <penberg@...helsinki.fi>, Pavel Machek <pavel@....cz>,
linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
akpm@...l.org, viro@...iv.linux.org.uk, tytso@....edu,
tigran@...itas.com
Subject: Re: [RFC/PATCH] revoke/frevoke system calls V2
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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists