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.
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.
>
>
> 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,
On Fri, 13 Oct 2000, Alan Cox wrote:
> > 1) one process does read() on device, another does revoke()
> > followed by rmmod. Oops - nothing holds module in memory, the first
> > process is executing code from that module (->read(), that is) and
> > we unmap that code.
> >
> > 2) every
> 1) one process does read() on device, another does revoke()
> followed by rmmod. Oops - nothing holds module in memory, the first
> process is executing code from that module (->read(), that is) and
> we unmap that code.
>
> 2) every access to ->f_op suddenly becomes unsafe.
On Fri, 13 Oct 2000, Dr. Werner Fink wrote:
>
> Hi,
>
> hopefully this mail isn't lost because of a nervous `d' finger ;^)
> Last week I've finished the work on the system call revoke for 2.4 and
> done some changes on it suggested by the vendors security list.
>
> Due to the security
Hi,
hopefully this mail isn't lost because of a nervous `d' finger ;^)
Last week I've finished the work on the system call revoke for 2.4 and
done some changes on it suggested by the vendors security list.
Due to the security issue of the syscall revoke, it would nice to see
this patch
On Fri, 13 Oct 2000, Alan Cox wrote:
1) one process does read() on device, another does revoke()
followed by rmmod. Oops - nothing holds module in memory, the first
process is executing code from that module (-read(), that is) and
we unmap that code.
2) every access to
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
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
10 matches
Mail list logo
