Quoting Pekka Enberg ([email protected]):
> On 1/10/07, Serge E. Hallyn <[email protected]> wrote:
> >Now, what slim needs isn't "revoke all files for this inode",
> >but "revoke this task's write access to this fd". So two functions
> >which could be useful are
> >
> > int fd_revoke_write(struct task_struct *tsk, int fd)
> > int fd_revoke_write_iter(struct task_struct *tsk,
> > (int *)need_revoke(struct task_struct *tsk, int
> > fd))
>
> This gets interesting. We probably need revokefs (which we use
> internally as a substitute for revoke inodes) to be stacked on top of
> the actual fs so that you can still read from the fd. But most of the
> revocation is still the same, we need to watch out for fork(2) and
> dup(2) and take down shared mappings.
Hmm, would revokefs need to be explicitly stacked on top of the fs,
or could we just swap out fdt[fd] for the revokefs file, and have
the revokefs file's private data point to the original inode, with
it's write function returning an error, and read being passed through?
Do you (or hch) then have a problem with these functions (sitting either
in fs/revoke.c or fs/file_table.c) calling mprotect to remove the write
permission from the mmap'ed segment? i.e. was the main objection to
mprotect being called from "just anywhere"?
-serge
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
