[lkml]   [2000]   [Oct]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch] For 2.4: syscall revoke.
So ... how can a revoke system call be implemented without changing vfs
too much? IMHO this system call is missed. There are some really interesting
interfaces using block or character devices which shouldn't be usable for users
because of the lack of secure revoking of such a device. Therefore we `disable'
such devices by allowing only root access because chmod/chown is not secure.
On the other hand we say our users: Please do not work as root due to the risks ...

On Fri, Oct 13, 2000 at 09:16:28PM -0400, Alexander Viro wrote:
> On Fri, 13 Oct 2000, Alan Cox wrote:
> > > writer might be OK, but AFAICS there is nothing of that sort in the
> > > tree. We have such spinlocks, but I don't see how to apply that idea to
> > > semaphores. Besides, it ought to be small - every struct file will have to
> > > contain such beast.
> >
> > It would mean a check when putting a file handle, which would be unpleasant
> > if not handled very carefully.
> I.e. you would have to unlock before doing fput(). Happens all by itself
> if we hold the lock only across the actual method call. I'm not saying
> that it's a good way, but correctenss problems are not going to be all
> that terrible.
> > How about doing this in fput ?
> >
> > if(IS_REVOKED(file) && file->f_ops != &revoked_ops)
> > {
> > file->f_ops = &revoked_ops;
> > wake_up(&fop_wait);
> > }
> >
> > that would mean that the ops change is done by the code paths that care about
> > the handle at the point it becomes unused. We could use a poll_table like
> > setup to handle the multi-fd wait if need be
> ?
> fput() has zero serialization wrt methods. The only case when resetting
> ->f_op in fput() is safe is when ->f_count hits zero. Precisely because
> there's no references left. But at that point you don't need to bother at
> all.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:41    [W:0.052 / U:4.628 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site