Ok, good question. Let's look at the permisstion issue:
I had this check in my revoke attempt:
+ retval = -EPERM;
+ if (!capable(CAP_DAC_OVERRIDE &&
+ current->fsuid != dentry->d_inode->i_uid)) {
+ goto out_dput;
+ }
I agree that revoke should be limited to block and char devices, this way
users that don't get ownership of a block/char device cannot do anything
bad with it.
Processes with capability CAP_DAC_OVERRIDE can open any file, so i think
CAP_DAC_OVERRIDE processes which get an EOF because of an user revoked his
block/char device, should be prepared to reopen it, so I see no need to
use a different revoke behavor in linux compared to BSD. It's there and
it would have been changed if there were any problem with it.
Comments?
- Bernd
>
> On Wed, 23 Jun 1999, Chris Evans wrote:
>
> > 2) The impact of allowing arbitrary users to call revoke() on files they
> > own is unassessed, making it very very dangerous. root-owned processes
> > often deal with users' files, and may not be prepared to deal with a file
> > descriptor disappearing from under them. Hence I suggest limiting this
> > call to block devices/char devices.
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/