[lkml]   [2004]   [Jun]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: In-kernel Authentication Tokens (PAGs)
    Kyle Moffett <> writes:

    > On Jun 12, 2004, at 19:58, Trond Myklebust wrote:
    > > So this would be more like an in-kernel keyring then?
    > Yeah, that seems about right.


    Disclaimer: I haven't looked at the LSM stuff.

    Surely the only logical reason to tag a process with extra security
    information /in the kernel/ is because that information is going to be
    used /by the kernel/. I can't think of a good reason to put a
    generalised keystore in the kernel.

    Distributed filesystem credentials are a sensible thing to associate
    with a process because then they can be easily used by the filesystem
    code. Keeping this information per-uid would be easier, but PAGs are
    more general.

    From that point of view, AFS PAGs boil down to the idea of annotating
    processes with authorisation tokens that can be easily used by the
    kernel. IIRC, in AFS, they just tack on a couple of magic
    supplementary GIDs. It is good if the "annotation" can be carried out
    by a userspace process.

    To be most useful for distributed filesystems, PAG ids should be
    per-process and inherited across fork/exec.

    This is somewhat different from the genereal idea of a keystore, or
    capabilities ala

    So that you can see where I'm coming from (and tell me I'm wrong :)
    here's my braindead idea of what generic PAG support would look like.
    I would be very surprised if there were not some more generic
    mechanism of which this is a subset. LSM?


    There needs to be some capability set to allow trusted processes to
    grant a PAG id to a process. In a simple implementation, say,
    CAP_PAG_ALLOCATE allows you to assign them. In some cases, the kernel
    might attach a PAG id to a process.

    Each process may have a list of PAG ids.

    A PAG id list entry has two important parts, a pag_domain [which might
    be PAG_DOMAIN_AFS or PAG_DOMAIN_CODA, whatever -- it just identifies
    the kernel subsystem to which the PAG is meaningful] and a pag_id,
    which is considered opaque.

    You might also have CAP_PAG_GIVEAWAY to allow giveaways by processes
    with PAG ids. I haven't thought that part through very well.

    A pag-er (allocator) needs at least:

    * some way to give a process a unique PAG id.
    * some subsystem specific support to associate more data with that PAG id.

    And the pag-ee needs at least:

    * some (allocator specific) way to ask for a PAG id. this happens in
    * some way to enumerate PAG ids.
    * some way to get rid of PAG ids.
    * perhaps some way to give PAG ids away.



    Hello. Just walk along and try NOT to think about your INTESTINES
    being almost FORTY YARDS LONG!! ; C-u M-x yow
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:03    [W:0.022 / U:5.532 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site