Docadmin at 21:20, 22 January 2010

2010-01-22T21:20:25Z

← Older revision		Revision as of 14:20, 22 January 2010
Line 1:		Line 1:
	'''''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.		'''''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 ==		== Linux Keyring ==

Docadmin: Protected "Architecture - PAG" ([edit=sysop] (indefinite) [move=sysop] (indefinite))

2010-01-22T18:51:17Z

Protected "Architecture - PAG" ([edit=sysop] (indefinite) [move=sysop] (indefinite))

← Older revision	Revision as of 11:51, 22 January 2010
(No difference)

Docadmin at 00:18, 19 January 2010

2010-01-19T00:18:05Z

← Older revision		Revision as of 17:18, 18 January 2010
Line 1:		Line 1:
			'''''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 ==		== Linux Keyring ==

Docadmin: /* Category */

2010-01-14T23:47:12Z

Docadmin: moved PAG to Architecture - PAG

2010-01-14T21:43:34Z

moved PAG to Architecture - PAG

← Older revision	Revision as of 14:43, 14 January 2010
(No difference)

Docadmin: 1 revision

2010-01-14T21:01:08Z

1 revision

← Older revision	Revision as of 14:01, 14 January 2010
(No difference)

Adilger: Minor grammar changes

2007-12-19T06:40:16Z

Minor grammar changes

New page

== 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. 

== Category ==
[[Category:Architecture|PAG]]

← Older revision		Revision as of 16:47, 14 January 2010
Line 108:		Line 108:
	- find existing root context for RPC.<br>		- find existing root context for RPC.<br>
	- server treat it as root access.<br>		- server treat it as root access.<br>

	~~== Category ==~~
	~~[[Category:Architecture\|PAG]]~~