Re: [PATCH] address_space_operations unification

From: Trond Myklebust (trond.myklebust@fys.uio.no)
Date: Sat May 06 2000 - 08:11:42 EST


>>>>> " " == Steve Dodd <steved@loth.demon.co.uk> writes:

>> I would have proposed something like this myself, but I got the
>> impression early on in the 2.3.x development that (at least
>> some) people involved in the VFS rewrite were violently opposed
>> to the idea.

> The only issue I can see is the one Al brought up earlier: if
> one process has a file mmap()d, and dirties a page, and then
> another process write()s the same page, the first process's
> changes will be sent with the credentials of the second. This
> could get nasty if the first process's permission to write had
> been revoked in the meantime (if this can happen).

Yes, but this is a fundamental problem with shared mmap() of files and
the fact that 2 different users are writing into the same page. It is
not an issue of credentials, but of the second process being forced to
flush the changes made by the first process together with its own
because the VM only has page-sized resolution. It is a problem that is
unaffected by what I want to change:

The purpose of passing the credentials down to the filesystem layer
(for NFS) is to ensure that we consistently use the same
authentication from file open() to file close() whenever we are
reading from and/or writing to that particular file.

Currently we just assume that the fsuid/fsgid of a given process never
changes which is obviously a false assumption. The struct file
contains a copy of the fsuid/fsgid that were used when checking
permissions upon open(), and can also be made to cache the full
corresponding rpc_cred at that time. This is what I wish to use in
order to ensure that reads and writes are authenticated in a
consistent fashion.

Cheers,
  Trond

-
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/



This archive was generated by hypermail 2b29 : Sun May 07 2000 - 21:00:19 EST