Re: RFC: BSD system call revoke?

[Bernd Kaindl]

On Thu, 24 Jun 1999, Matti Aarnio wrote:

> 	I would like to see call numbers and entry vector diffs for
> 	Alpha, SPARCs, MIPSes, ... as well.

Of course, when we have a generic implementation we all agree on, this
should be a simple step.

> 	I do find this thing a bit surprising, I had thought we already
> 	had this facility in the kernel ???  Perhaps not then ?

Thanks to all which have also responed, i think i've found one version
of the patch:

http://www.uwsg.indiana.edu/hypermail/linux/kernel/9712.1/0098.html

Is this the last version of the patch?

> 	Changeing f_op field in the associated 'struct file' to point
> 	to the revocation file operations set(s) would be the easiest way.
>
Yes, i saw it in the patch.

> 	One way is shown at the  drivers/char/tty_io.c  with the way
> 	how hungup is handled by changeing the filp->f_op field.

Good pointer! The patch i found can be enhanced to do it likewise.

> 	Another approach would be to pick the 'inode' from below the file,
> 	and then call   make_bad_inode(inode)  at it.
> 
> 	Basically the idea is to ruin the file completely, and the only
> 	f_op operation doable to the file is close().  All others yield
> 	-EIO.

May also be possible, we just should use better stubs like in char/tty_io.c

> 	Also, less multiprocessing hazards at the change of f_op, when
> 	compared to going in and calling filp_close() at all files which
> 	get same "kill" treatment...

I also think so, i'm interested what Al Viro is saying about the f_op.

One thing I miss in the patch i found is what Chris pointed out:
>
> 1) It is not sufficient to just close the file descriptor. Some
> potentially sensitive devices (and all files) may by mmap()'ed into
> virtual memory. I think the solution was vmtruncate()
 
Question one: Is this the last version of the revoke patch?
Question two: Al Viro, what are you saying?

-- 

have a nice day,

  (-:B-e-r-n-d;-)