strange behaviour between linux server and sunos client - NFS

This is a discussion on strange behaviour between linux server and sunos client - NFS ; hello, I recently change my nfsserver from solaris 7 to linux suse enterprise 8.0 SP 3 . The file system options for export were rw in solaris and are now rw,no_root_squash,sync for linux. This works well until i discover the ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: strange behaviour between linux server and sunos client

  1. strange behaviour between linux server and sunos client

    hello,

    I recently change my nfsserver from solaris 7 to linux suse enterprise
    8.0 SP 3 .
    The file system options for export were rw in solaris and are now
    rw,no_root_squash,sync for linux.

    This works well until i discover the following behaviour:

    on sunos client ( 4.1.4 ) user can modify a read-only file with
    textedit and i can do the same with vi ( with w! ) .

    So i try the same operation directly on servers and on solaris i
    cannot update a readonly file with vi but in linux it is possible (
    vim improvement ??? ).
    i try too echo "hello" >> readonly_file and it does not work on both
    systems :-)


    Any hints

    Thanks

    Francis

  2. Re: strange behaviour between linux server and sunos client

    francis.berges@laposte.net (francis.berges@laposte.net) wrote in message news:...
    > hello,
    >
    > I recently change my nfsserver from solaris 7 to linux suse enterprise
    > 8.0 SP 3 .
    > The file system options for export were rw in solaris and are now
    > rw,no_root_squash,sync for linux.
    >
    > This works well until i discover the following behaviour:
    >
    > on sunos client ( 4.1.4 ) user can modify a read-only file with
    > textedit and i can do the same with vi ( with w! ) .


    Are you doing this as root (uid == 0)?

    Can the Solaris client do the same to the suse NFS server?

    Are you using NFSv2 for all your apples to apples tests?

    >
    > So i try the same operation directly on servers and on solaris i
    > cannot update a readonly file with vi but in linux it is possible (
    > vim improvement ??? ).
    > i try too echo "hello" >> readonly_file and it does not work on both
    > systems :-)
    >
    >
    > Any hints



    You should post a matrix of client versus server, and keep the NFS version
    constant (version 2).

  3. Re: strange behaviour between linux server and sunos client

    francis.berges@laposte.net (francis.berges@laposte.net) wrote in message news:...
    > hello,
    >
    > I recently change my nfsserver from solaris 7 to linux suse enterprise
    > 8.0 SP 3 .
    > The file system options for export were rw in solaris and are now
    > rw,no_root_squash,sync for linux.
    >
    > This works well until i discover the following behaviour:
    >
    > on sunos client ( 4.1.4 ) user can modify a read-only file with
    > textedit and i can do the same with vi ( with w! ) .
    >
    > So i try the same operation directly on servers and on solaris i
    > cannot update a readonly file with vi but in linux it is possible (
    > vim improvement ??? ).
    > i try too echo "hello" >> readonly_file and it does not work on both
    > systems :-)


    To avoid hassles w.r.t. chmods being done to open files, most NFS
    servers
    allow the owner of a file to write it, regardless of the mode bits.
    (My
    current BSD server has a variable that a sysadmin can use to turn this
    on
    and off.) For my server, this only applies to AUTH_SYS, but that is
    what
    you are using. (An NFS server is stateless and, as such, has no idea
    that
    a client has a file open. On the other hand, POSIX only checks file
    access
    permissions on Open, so the server can either "fail the write, which a
    POSIX
    application won't expect" or "cheat a bit and allow the owner to write
    the
    file, even if the mode bits are read-only". The assumption is that
    "write
    mode" was checked by the client at Open and is therefore ok to do
    later.)

    What I believe should happen is the open for writing should fail.
    Typically a client will do an Access RPC as a part of the Open (or
    check the mode bits via a
    Getattr) to do this. You might use snoop to look at what is happening.
    (You might also try switching between V2 and V3, since the Access RPC
    is
    only a part of V3.)

  4. Re: strange behaviour between linux server and sunos client

    rmacklem@uoguelph.ca (Rick Macklem) writes:

    >francis.berges@laposte.net (francis.berges@laposte.net) wrote in message news:...
    >> hello,


    >> on sunos client ( 4.1.4 ) user can modify a read-only file with
    >> textedit and i can do the same with vi ( with w! ) .


    You probably should look at a packet trace. Or change your server back
    to Solaris.

    >To avoid hassles w.r.t. chmods being done to open files, most NFS servers
    >allow the owner of a file to write it, regardless of the mode bits.


    It's not so much for chmod's but for:

    fd = open(file, O_WRONLY|O_CREAT, 0444);

    (Create a read-only file and open it for writing)

    Note that for multiple programs on the same system the behaviour should
    be different: the first to create/open the file can write to it all the
    others shouldn't. Typically there's a little dance of NFS_ACCESS
    (not available in NFSv2) or local interpretation of the mode bits done
    by the client.

    Typically the server computes write permissions as
    "allowed by file permission" OR "writer is owner" which works
    nicely for the create but doesn't work for other cases.

    >What I believe should happen is the open for writing should fail.
    >Typically a client will do an Access RPC as a part of the Open (or
    >check the mode bits via a
    >Getattr) to do this. You might use snoop to look at what is happening.
    >(You might also try switching between V2 and V3, since the Access RPC
    >is
    > only a part of V3.)


    Since the client in question is SunOS 4.1.4, it only has NFSv2 and
    so it doesn't call access; AFAIK, the SunOS 4.x client code does its
    own access checking so there must be something weird in the SuSE NFS
    server, I think.

    Casper

+ Reply to Thread