Re: [PATCH] address_space_operations unification

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

  • Next message: kuznet@ms2.inr.ac.ru: "Re: Forwarding information base (sketch, & qs on trie)"

    >>>>> " " == 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 : Sat May 06 2000 - 09:17:58 EDT