Architecture - PAG

Note: The content on this page reflects the state of design of a Lustre feature at a particular point in time and may contain outdated information.

Linux Keyring

Lustre uses the Linux keyring facility in session based manner, which means a key is accessible only by processes which belong to a single session. Forked process will inherit its parent's keys. If the same user logs in twice it will result in two context negotiations with the Lustre server.

Lustre treats the root user specially - all processes of the root user share a single key, regardless of session ID.

Setuid in Lustre

Lustre authenticates users based on the real UID instead of fsuid. A process that changes its fsuid won't need extra authentication, but the server will detect the setuid attempt and perform according to preset rules. If the real UID is changed, the new UID has to be authenticated with the server before any further access is allowed.

Usually a process has no reason to change its real UID alone (right?). In the case that a process of A sets its real UID to 0 (with fsuid still be A), the Lustre server will still treat it as root set fsuid to A.

Kerberos credential

There are two possible ways to store Kerberos tickets which affect PAG behavior:

1) on disk (/tmp/krb5cc_uid) root is able to read other user's tickets anyway. So root can impersonate other uses by simply "su", although it will initiate a new authentication, it can always succeed because it have access to on-disk kerberos tickets.

2) in kernel memory A user can store kerberos ticket only in kernel memory via keyring facility, and only processes belongs to the same session could have access, even not root.

Use Case

The use cases are based on method (2) above (store kerberos credential in kernel memory).

1) root access
- root process accesses Lustre for the first time.
- initiate an authentication of root with server.
- finish with success, store context in keyring.
- using the context for following RPCs.
- another root process (from the same session or not) access Lustre.
- find the existing context in kernel, use it for following RPCs.

2) non-root access
- user A logs into the system as session S1.
- obtain kerberos TGT and store in kernel keyring.
- user A accesses Lustre, which initiate an authentication of A.
- the stored kerberos TGT is used in authentication.
- upon successful completion, store context for S1.
- using the context for following RPCs.

- a new process forked in S1, which accesses Lustre also.
- find the existing context of S1, use it for following RPCs.

- user A login system from another tty as session S2.
- user A in S2 accesses Lustre.
- can't find existing context, initiate authentication of A.
- can't find kerberos TGT, authentication failed.
- access failed

- in S2, A obtain TGT and store in kernel keyring.
- user A in S2 access Lustre again.
- can't find existing context, initiate authentication of A.
- the stored kerberos TGT is used in authentication.
- finish with success, store context for S2.
- using the context for following RPCs.

3) root try to act as A support both root and A have login system and authenticated with Lustre servers.

3.1)
- root set fsuid to A, access Lustre.
- find existing root context for RPC.
- server detect root try to setuid to A, grant or deny.

3.2)
- root set real uid to A, access Lustre.
- can't find existing context, initiate authentication of A.
- can't find kerberos TGT, authentication failed.
- access failed.

3.3)
- root do "su - A", start a shell with new session.
- access Lustre.
- can't find existing context, initiate authentication of A.
- can't find kerberos TGT, authentication failed.
- access failed.

4) user A setuid to root
support both root and A have login system and authenticated with Lustre servers.

4.1)
- process of A set fsuid to root, access Lustre.
- find existing context of A for this session for RPC.
- server detect A try to setuid to root, grant or deny.
4.2)
- process of A set real uid to root, access Lustre.
- find existing root context for RPC.
- server treat it as root try to setuid to A, grant or deny.
4.3)
- process of A set real uid and fsuid to root, access Lustre.
- find existing root context for RPC.
- server treat it as root access.