DragonFly BSD
DragonFly bugs List (threaded) for 2003-10
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: NFS truncates files

From: Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>
Date: Tue, 7 Oct 2003 14:36:35 -0700 (PDT)

:   I have a home directory mount via nfs.  The nfs server does not have
:-maproot set so root's uid/gid are mapped to -2 (at least according to the man
:page).  When I edit a file in my home directory I receive "permission
:denied:file truncated" upon a write.  File and directory creation is not
:affected, only the modification of the file.  The uid attempting to modify
:these thing the file is 1000.  If I set -maproot=root on the server everything
:behaves as expected.
:   I believe src/sys/vfs/nfs_vnops.c to be the source of the problem.  Version
:1.10 of this file is supposed to fix a file truncation problem.  Version 1.12
:of this file contains changes related to the vfs work that is in progress.
:   Example:
:Script started on Tue Oct  7 10:46:33 2003

    Ok, I can replicate the problem easily.  The issue is related to some
    VOP_WRITE cleanups I had done a month or two ago.  Once a valid file
    handle is in hand one should be able to theoretically initiate writes
    without having to pass the credential, so I removed the credential and
    NFS just passes the root credential.

    In the case of a mount without -maproot the writes as root will actually
    write (on the server) as uid -2, which is why it fails.

    You can temporarily correct the problem for your home directory mount
    by setting -maproot to your user id on the server instead of omiting it.
    I'm not what the proper solution is... it's actually a server side issue
    (the lack of a maproot should not simply map root to uid -2, but should
    instead allow the client to use root creds for everything *except* root),
    but in order to maintain compatibility with other nfs servers we may have
    to come up with a client-side solution.  I would really like to avoid
    record the ucred as part of the I/O because it pollutes struct buf and
    VOP_WRITE and fails utterly (even on 4.x) if a write is initiated by
    the pageout code instead of directly with WRITE because the pageout code
    has no notion of uids either.

    Perhaps the solution is to record the ucred used to gain write-access 
    to the nfsnode and use that in the NFS write operation.


[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]