1 #LyX 1.3 created this file. For more info see http://www.lyx.org/
15 \use_numerical_citations 0
16 \paperorientation portrait
19 \paragraph_separation skip
21 \quotes_language english
25 \paperpagestyle default
29 High Level Design of User Revoke
41 Be able to revoke a user, prevent it from accessing lustre immediately.
44 Be able to pass sub-test of HP acceptance 4.1.51.
47 user & mapping databases manipulation API.
50 Functional Specification
54 \begin_inset Quotes eld
58 \begin_inset Quotes erd
61 will be added into existing tool 'lctl'.
62 When system administrator want to kick somebody off from lustre filesystem
64 a certain user has known be malicious or an account be compromised), he
65 could use this functionality on MDS's to prevent the victim user from access
66 lustre filesystem right away.
67 The command format could be:
73 Here the 'user' format is: uid[@nid[.netid]]
76 option @nid.netid is only for remote users.
77 The uid is in term of local uid, thus 'uid@remote_nid.netid' means remote
78 users on node 'remote_nid.netid' who are mapped to local 'uid', it's not
79 intend to remove a certain user on specific node.
82 Specified uid without nid or netid means match all nid or netid.
85 'all' means revoke all users.
88 Actually lctl only remove those in-kernel cache for the victim user, usually
89 there's many other configuration work need to be done by using other admin
93 Kerberos Database: For removing a user from kerberos principal database,
94 sysadmin must use kerberos admin tools.
95 And this change will not take effect right away if the victim user has
96 authenticated with MDS's before the removal (because of client side credential
100 User Database: For removing a user from user database, sysadmin also must
101 resort to other tools, usually standard unix tools.
102 This change will not take effect right away if this user had ever accessed
103 lustre before the removal (because of in-kernel LSD cache).
106 User Mapping Database: For removing a user from remote user mapping database,
107 sysadmin need edit the configure file manually.
108 This only affect certain user on certain remote client.
109 This change will not take effect right away if this user had ever acessed
110 lustre before the removal (because of in-kernel uid mapping cache).
113 So when sysadmin actually revoke a user, he usually at first did one or
114 more steps of above according to requirement, then invoke lctl to finally
116 In cases that user database or user mapping database are not centrally
118 LDAP, sysadmin must remove the user from all configure files on each MDS's,
119 this could be done by using 'pdsh', etc.
122 What above described is the basic requirement.
123 There's an additional one: for user and mapping database, write a C API
124 library (probably later add python support), which can query, add, remove,
125 and enumerate users in each database.
126 'edit' could be implemented as remove + add.
129 By using this API, we could provide much complete functionality.
130 Sysadmin could do everything about user account within single lctl tools;
131 Kernel upcall helper also could use this API to obtain information from
132 mapping database, etc.
138 Revoke Alice's access right on all clients, permanently
141 Sysadmin remove Alice from user database on all MDS's.
144 Sysadmin invoke 'lctl revoke alice_uid' on all MDS's.
147 Alice from local clients will not be able to access lustre.
150 Any remote users who are mapped to Alice will not be able to access lustre.
153 Revoke Alice's access right on remote client remote1
156 Suppose alice@remote1 is mapped to local user Bob.
159 Sysadmin remove mapping entry of 'alice_uid@remote1 -> bob' from user mapping
163 Sysadmin invoke 'lctl revoke bob_uid@remote1' on all MDS's.
166 Alice will not be able to access lustre from remote1.
169 Bob from an local client could still work fine.
175 There's several kinds of in-kernel cache for certain user: LSD, gss context,
177 In the future we might add consideration of removing OSS access capability.
180 LSD: On each MDS, each user (uid) correspond to at most one LSD entry.
181 There's already an existing interface to flush LSD for a certain user:
182 simply write an uid into '/proc/fs/lustre/mds/lsd_flush' (Note this is
184 Write in '-1' will flush all LSD entries.
187 GSS Context: On each MDS, each user (principal) might correspond to several(even
189 The gss module should export a proc entry.
190 When provided uid and remote nid/netid, it should be able to find out the
191 initiating/established gss contexts and destroy them.
192 Providing a special tag will flush all gss contexts.
195 UID Mapping: Firstly found out per-client structure for specified nid/netid,
196 then destroy the mapping entries for specified uid.
197 Since this is strongly related to GSS context, we can use the export proc
198 entry for gss context to initiate this flush.
199 Thus when sysadmin trying to flush gss contexts for certain user, we also
200 flush associated uid-mapping.
203 This work should be done after the completion of GSS and remote uid/gid
204 handling implementation.
207 The user and mapping databases manipulation API could be simple not much
208 restriction, and the details is very much related to the actual database
210 we leave the details to the following DLD document.
216 Since we'll flush several cache separately, we might have situation that
217 not strictly consistency.
218 For example, after we flushed alice from cache1, someone re-populate it
219 in cache1 while do it on cache2.
220 In fact, the inconsistency between LSD and gss context is perfectly allowed.
221 Only one thing need be sure is: since uid mapping is established after
222 that of gss context, thus we need flush uid mapping at first, and then
224 This could prevent unnecessary error when doing 'revoke' while we don't
225 actually remote it from mapping database.
228 No serious locking issues, no special recovery consideration.
240 Is the lctl interface reasonably reflect the facts?
243 Could it pass acceptance test?