16 Oct, 2007

1 commit

  • * git://git.linux-nfs.org/pub/linux/nfs-2.6: (131 commits)
    NFSv4: Fix a typo in nfs_inode_reclaim_delegation
    NFS: Add a boot parameter to disable 64 bit inode numbers
    NFS: nfs_refresh_inode should clear cache_validity flags on success
    NFS: Fix a connectathon regression in NFSv3 and NFSv4
    NFS: Use nfs_refresh_inode() in ops that aren't expected to change the inode
    SUNRPC: Don't call xprt_release in call refresh
    SUNRPC: Don't call xprt_release() if call_allocate fails
    SUNRPC: Fix buggy UDP transmission
    [23/37] Clean up duplicate includes in
    [2.6 patch] net/sunrpc/rpcb_clnt.c: make struct rpcb_program static
    SUNRPC: Use correct type in buffer length calculations
    SUNRPC: Fix default hostname created in rpc_create()
    nfs: add server port to rpc_pipe info file
    NFS: Get rid of some obsolete macros
    NFS: Simplify filehandle revalidation
    NFS: Ensure that nfs_link() returns a hashed dentry
    NFS: Be strict about dentry revalidation when doing exclusive create
    NFS: Don't zap the readdir caches upon error
    NFS: Remove the redundant nfs_reval_fsid()
    NFSv3: Always use directory post-op attributes in nfs3_proc_lookup
    ...

    Fix up trivial conflict due to sock_owned_by_user() cleanup manually in
    net/sunrpc/xprtsock.c

    Linus Torvalds
     

10 Oct, 2007

2 commits

  • We've let svcauth_gss_accept() get much too long and hairy. The
    RPC_GSS_PROC_INIT and RPC_GSS_PROC_CONTINUE_INIT cases share very little
    with the other cases, so it's very natural to split them off into a
    separate function.

    This will also nicely isolate the piece of code we need to parametrize
    to authenticating gss-protected NFSv4 callbacks on behalf of the NFS
    client.

    Signed-off-by: J. Bruce Fields
    Acked-by: Neil Brown

    J. Bruce Fields
     
  • Use correct type signage in gss_krb5_remove_padding() when doing length
    calculations. Both xdr_buf.len and iov.iov_len are size_t, which is
    unsigned; so use an unsigned type for our temporary length variable to
    ensure we don't overflow it..

    Signed-off-by: Chuck Lever
    Signed-off-by: "J. Bruce Fields"
    Signed-off-by: Trond Myklebust

    Chuck Lever
     

14 Aug, 2007

1 commit


08 Aug, 2007

1 commit


25 Jul, 2007

1 commit

  • The handling of the re-registration case is wrong here; the "test" that was
    returned from auth_domain_lookup will not be used again, so that reference
    should be put. And auth_domain_lookup never did anything with "new" in
    this case, so we should just clean it up ourself.

    Thanks to Akinobu Mita for bug report, analysis, and testing.

    Cc: Akinobu Mita
    Signed-off-by: "J. Bruce Fields"
    Cc: Neil Brown
    Cc: Trond Myklebust
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    J. Bruce Fields
     

20 Jul, 2007

1 commit


19 Jul, 2007

1 commit


18 Jul, 2007

4 commits

  • We could return some sort of error in the case where someone asks for secinfo
    on an export without the secinfo= option set--that'd be no worse than what
    we've been doing. But it's not really correct. So, hack up an approximate
    secinfo response in that case--it may not be complete, but it'll tell the
    client at least one acceptable security flavor.

    Signed-off-by: "J. Bruce Fields"
    Signed-off-by: Neil Brown
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    J. Bruce Fields
     
  • Adds oid values to the gss_api mechanism structures. On the NFSV4 server
    side, these are required as part of the security triple (oid,qop,service)
    information being sent in the response of the SECINFO operation.

    Signed-off-by: Usha Ketineni
    Signed-off-by: "J. Bruce Fields"
    Signed-off-by: Neil Brown
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Usha Ketineni
     
  • We want it to be possible for users to restrict exports both by IP address and
    by pseudoflavor. The pseudoflavor information has previously been passed
    using special auth_domains stored in the rq_client field. After the preceding
    patch that stored the pseudoflavor in rq_pflavor, that's now superfluous; so
    now we use rq_client for the ip information, as auth_null and auth_unix do.

    However, we keep around the special auth_domain in the rq_gssclient field for
    backwards compatibility purposes, so we can still do upcalls using the old
    "gss/pseudoflavor" auth_domain if upcalls using the unix domain to give us an
    appropriate export. This allows us to continue supporting old mountd.

    In fact, for this first patch, we always use the "gss/pseudoflavor"
    auth_domain (and only it) if it is available; thus rq_client is ignored in the
    auth_gss case, and this patch on its own makes no change in behavior; that
    will be left to later patches.

    Note on idmap: I'm almost tempted to just replace the auth_domain in the idmap
    upcall by a dummy value--no version of idmapd has ever used it, and it's
    unlikely anyone really wants to perform idmapping differently depending on the
    where the client is (they may want to perform *credential* mapping
    differently, but that's a different matter--the idmapper just handles id's
    used in getattr and setattr). But I'm updating the idmapd code anyway, just
    out of general backwards-compatibility paranoia.

    Signed-off-by: "J. Bruce Fields"
    Signed-off-by: Neil Brown
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    J. Bruce Fields
     
  • Add a new field to the svc_rqst structure to record the pseudoflavor that the
    request was made with. For now we record the pseudoflavor but don't use it
    for anything.

    Signed-off-by: Andy Adamson
    Signed-off-by: "J. Bruce Fields"
    Signed-off-by: Neil Brown
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andy Adamson
     

17 Jul, 2007

1 commit

  • Recent breakage..

    net/sunrpc/auth_gss/auth_gss.c:1002: warning: implicit declaration of function 'lock_kernel'
    net/sunrpc/auth_gss/auth_gss.c:1004: warning: implicit declaration of function 'unlock_kernel'

    Cc: Trond Myklebust
    Cc: "J. Bruce Fields"
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andrew Morton
     

11 Jul, 2007

16 commits


10 Jul, 2007

1 commit


10 May, 2007

3 commits

  • If I send a RPC_GSS_PROC_DESTROY message to NFSv4 server, it will reply with a
    bad rpc reply which lacks an authentication verifier. Maybe this patch is
    needed.

    Send/recv packets as following:

    send:

    RemoteProcedureCall
    xid
    rpcvers = 2
    prog = 100003
    vers = 4
    proc = 0
    cred = AUTH_GSS
    version = 1
    gss_proc = 3 (RPCSEC_GSS_DESTROY)
    service = 1 (RPC_GSS_SVC_NONE)
    verf = AUTH_GSS
    checksum

    reply:

    RemoteProcedureReply
    xid
    msg_type
    reply_stat
    accepted_reply

    Signed-off-by: Wei Yongjun
    Signed-off-by: "J. Bruce Fields"
    Signed-off-by: Neil Brown
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Wei Yongjun
     
  • I have been investigating a module reference count leak on the server for
    rpcsec_gss_krb5.ko. It turns out the problem is a reference count leak for
    the security context in net/sunrpc/auth_gss/svcauth_gss.c.

    The problem is that gss_write_init_verf() calls gss_svc_searchbyctx() which
    does a rsc_lookup() but never releases the reference to the context. There is
    another issue that rpc.svcgssd sets an "end of time" expiration for the
    context

    By adding a cache_put() call in gss_svc_searchbyctx(), and setting an
    expiration timeout in the downcall, cache_clean() does clean up the context
    and the module reference count now goes to zero after unmount.

    I also verified that if the context expires and then the client makes a new
    request, a new context is established.

    Here is the patch to fix the kernel, I will start a separate thread to discuss
    what expiration time should be set by rpc.svcgssd.

    Acked-by: "J. Bruce Fields"
    Signed-off-by: Frank Filz
    Signed-off-by: Neil Brown
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Frank Filz
     
  • It's not necessarily correct to assume that the xdr_buf used to hold the
    server's reply must have page data whenever it has tail data.

    And there's no need for us to deal with that case separately anyway.

    Acked-by: "J. Bruce Fields"
    Signed-off-by: Neil Brown
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    NeilBrown
     

02 May, 2007

3 commits


13 Feb, 2007

1 commit


11 Feb, 2007

1 commit


04 Feb, 2007

1 commit


23 Dec, 2006

1 commit