lkml.org 
[lkml]   [2002]   [Aug]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [PATCH 2.5.30+] Fourth attempt at a shared credentials patch
    Date
    In article <55560000.1028921049@baldur.austin.ibm.com>,
    Dave McCracken <dmccr@us.ibm.com> wrote:
    >
    >--On Thursday, August 08, 2002 11:55:05 PM +0200 Trond Myklebust
    ><trond.myklebust@fys.uio.no> wrote:
    >
    >> What if one thread is doing an RPC call while the other is changing
    >> the 'groups' entry?
    >
    >Gah. Good point. Ok, I've added locking to the cred structure to handle
    >this.

    Please don't do this with locking, I really think the right thing to do
    is to have a "duplicate()" function, and when you pass credentials off
    to something, you dup them at that point.

    If you start off as non-root, and then execve suid into root, a pending
    NFS request should _not_ suddently have the credentials changed under
    it. Yet clearly that kind of thing can't just be locked either.

    Along with copy-on-write semantics, this should perform perfectly well
    (ie "duplicate()" would only increment a count, and then setuid() would
    have to have code soemthing like

    if (cred->count > 1) {
    newcred = alloc_cred();
    copy_cred(newcred, cred);
    for_each_cred_group(p) {
    p->cred = newcred;
    atomic_inc(&newcred->count);
    putcred(cred);
    }
    }

    instead.

    Linus
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:27    [W:0.084 / U:60.168 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site