lkml.org 
[lkml]   [2003]   [May]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [OpenAFS-devel] Re: [PATCH] PAG support, try #2
    Date
    From

    > > For any process where pag != 0, that process will share
    > > tokens with all other processes that have the exact same
    > > pag value as it has. This is true even if the different
    > > processes are tied to different user ids.
    >
    > Yeah, and the thing I think it _totally_ and utterly broken is that there
    > can be only one of these per process.
    >
    > I don't see where the 1:1 idea comes from, except from a bad
    > implementation.

    Where's this 1:1 come from? PAGs aren't 1:1 with processes, nor are they 1:1
    with users.

    I've tried to implement them as I understand the design information I could
    find (which specified that any process could belong to a single PAG). From the
    comments that have been made, it seems that each user needs some sort of
    fallback token set for any process that doesn't have a PAG.

    > > There is absolutely no connection between userids and PAG's,
    > > the same way that there is no connection between userids and
    > > process-numbers. (Roughly speaking:) The 10th person to log
    > > in will get the 10th pag, no matter what userid they happen
    > > to log in as.
    >
    > And this is also again nothing but the result of a bad implementation.

    That's the design.

    Since AFS uses the PAG as part of the lookup key, it seemed reasonable to make
    a more formal association between the credential ring and the PAG in the
    kernel (especially as I needed someway of (a) generating a unique PAG, and (b)
    performing garbage collection on PAGs).

    > From a system maintenance issue, this is a nightmare. It makes joining a
    > group nigh impossible, since now the joiner (login or something) has to
    > keep track of what pag's it has used for previous logins. Which is fine as
    > long as you have _one_ login authority, but it's a total disaster to
    > require that kind of centralization.

    Adding credentials to groups seems to be tricky (if not superfluous - surely
    that's what ACLs are for).

    Who should add creds to groups? And assuming like kerberos is used, wouldn't
    the lifetime a credential attached to a group then be dependent in some way on
    the authorisation granted to the user who requested the group cred in the
    first place?

    It's also not a total disaster to have a central login authority (assuming I'm
    understanding your objection correctly). It's necessary for many reasons
    (including distributed filesystems), and is supported any many ways: kerberos,
    YP/NIS, M$ SMB, LDAP.

    It seems to me that what is required is a ring of tokens, each of which says:

    When accessing data in domain "A" using protocol "B", present myself
    as user "C" using credential "D" from authority "E".

    Then the servers in domain "A" say:

    User "C" is trying to read datum "F". I validated his/her presented
    credential against "E". Datum "F" may be accessed in certain ways by
    users "G" and "H" and the members of groups "I", "J" and "K". Aha!
    User "C" is in group "J", and members of "J" are allowed to read "F",
    write "F" and turn "F" into a can of spam. Okay, "C" is allowed to
    read it.

    But what do you do for a group credential?

    When accessing data in domain "A" using protocol "B", present myself
    as group "J" using credential "D" from authority "E".

    This isn't good - if group management is handled on the client, the server
    then has to be able to trust the client absolutely.

    You could add a credential to a group so that users accessing files in a
    particular domain do so as a special user (use the user "engineering" for
    example when accessing files in devel.redhat.com), but I suspect that sort of
    thing isn't really what you want. I think that what you want there is ACLs.

    Furthermore, I think a process's gid and groups[] are something of a dead
    herring in this respect. They are a primitive ACL-like mechanism that's fine
    for UNIX local filesystems (in which case the kernel acts as its own
    authority), but don't necessarily map to network filesystems (though they are
    used by NFS/RPC doing AUTH_UNIX).

    Furthermore, PAGs and your group rings ought to self-destruct when nobody is
    referring to them as they consume kernel resources.

    > Right now the limited PAG namespace as implemented by the current patch
    > means that a PAG ID number _has_ to be throw-away: the namespace is too
    > small to give users permanent PAG ID's.

    PAG IDs are designed to be throw-away.

    > That's fine per se: you can always create a mapping layer in some
    > outside-of-the-kernel way (ie a database of "user -> currently used PAG
    > space"), but it's so much easier - I think - to just make the name space big
    > enough that you can have a trivial static mapping "user -> permanent PAG
    > ID".

    You'd still need the outside-of-the-kernel database or whatever. Otherwise,
    what would the ID numbers mean? After all, how do you know which UID number
    corresponds to your account?

    The ability to join PAGs is mostly unnecessary, it's just that it seems the
    facility is useful for a few specialised purposes (NFS->AFS translator being
    the primary one IIRC), and could possibly be dispensed with.

    It may be worth doing three things to my patch:

    (1) Discard setpag(pag_t).

    (2) Make pag_t either unsigned long (though this may cause problems when
    running a 32-bit program on a 64-bit arch) or unsigned long long and
    returned through a dereferenced pointer.

    (3) Add a default PAG to every struct user and add a syscall to attach the
    process to this PAG instead of what it is currently using.

    Though I don't expect you'll agree to that.

    It's not that I'm particularly attached to PAGs, it's just that they're a
    simple way of doing what I require.

    David
    -
    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:35    [W:0.029 / U:59.936 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site