Lines Matching refs:of
11 (*) Types of credentials.
25 (*) Overriding the VFS's use of credentials.
38 userspace programs. Linux has a variety of actionable objects, including:
48 As a part of the description of all these objects there is a set of
49 credentials. What's in the set depends on the type of object.
53 Amongst the credentials of most objects, there will be a subset that
54 indicates the ownership of that object. This is used for resource
62 Also amongst the credentials of those objects, there will be a subset that
63 indicates the 'objective context' of that object. This may or may not be
67 The objective context is used as part of the security calculation that is
74 Most of the objects in the system are inactive: they don't act on other
85 A subject has an additional interpretation of its credentials. A subset
86 of its credentials forms the 'subjective context'. The subjective context
87 is used as part of the security calculation that is carried out when a
92 from the real UID and GID that normally form the objective context of the
97 Linux has a number of actions available that a subject may perform upon an
98 object. The set of actions available depends on the nature of the subject
108 action, and searching one or more sets of rules to see whether the subject
112 There are two main sources of rules:
116 Sometimes the object will include sets of rules as part of its
121 is an abbreviated ACL with three fixed classes of subject ('user',
122 'group' and 'other'), each of which may be granted certain privileges
125 specification of subjects, however, and so are of limited use.
127 A Linux file might also sport a POSIX ACL. This is a list of rules
132 The system as a whole may have one or more sets of rules that get
133 applied to all subjects and objects, regardless of their source.
134 SELinux and Smack are examples of this.
136 In the case of SELinux and Smack, each object is given a label as part
137 of its credentials. When an action is requested, they take the
146 The Linux kernel supports the following types of credentials:
155 derived from Windows). These (mostly) define the objective context of
169 Set of permitted capabilities
170 Set of inheritable capabilities
171 Set of effective capabilities
185 make use of itself.
205 accesses performed by processes, without the necessity of ordinary
208 Keyrings are a special type of key. They carry sets of other keys and can
210 of keyrings:
217 cached on one of these keyrings for future accesses to find.
227 Some work by labelling the objects in a system and then applying sets of
239 When a file is opened, part of the opening task's subjective context is
241 struct to use those credentials instead of the subjective context of the task
242 that issued the operation. An example of this would be a file opened on a
243 network filesystem where the credentials of the opened file should be presented
244 to the server, regardless of who is actually doing a read or a write upon it.
252 objective security context of that file. Depending on the type of filesystem,
253 this may include one or more of the following:
268 operations allowed or disallowed as a result. In the case of execve(), the
277 In Linux, all of a task's credentials are held in (uid, gid) or through
278 (groups, keys, LSM security) a refcounted structure of type 'struct cred'.
282 Once a set of credentials has been prepared and committed, it may not be
296 (6) the contents of any keyrings to which it points may be changed (the whole
297 point of keyrings being a shared set of credentials, modifiable by anyone
307 longer permitted to take any PID other than the one of the current process.
316 Once a set of credentials has been made public (by calling commit_creds() for
321 (2) Whilst the keyring subscriptions of a set of credentials may not be
335 to read or replace its own credentials without the need for any form of locking
343 There are convenience wrappers for retrieving specific aspects of a task's
356 There are also convenience wrappers for retrieving specific associated pairs of
363 which return these pairs of values through their arguments after retrieving
368 process's current set of credentials:
372 and functions for getting references to one of the credentials that don't
389 same is not true of a task wanting to access another task's credentials. It
411 Should it be necessary to hold another task's credentials for a long period of
417 This does all the RCU magic inside of it. The caller must call put_cred() on
420 [*] Note: The result of __task_cred() should not be passed directly to
423 There are a couple of convenience functions to access bits of another task's
434 should be used instead. Similarly, if multiple aspects of a task's credentials
440 Should some other single aspect of another task's credentials need to be
445 where 'member' is a non-pointer member of the cred struct. For instance:
458 alter those of another task. This means that it doesn't need to use any
462 new set of credentials by calling:
467 duplicate of the current process's credentials, returning with the mutex still
468 held if successful. It returns NULL if not successful (out of memory).
470 The mutex prevents ptrace() from altering the ptrace state of a process whilst
472 the ptrace state may alter the outcome, particularly in the case of execve().
475 checks and hooks done. Both the current and the proposed sets of credentials
485 This will alter various aspects of the credentials and the process, giving the
489 the scheduler and others of the changes.
492 end of such functions as sys_setresuid().
497 Furthermore, once this function has been called on a new set of credentials,
539 This releases a reference to the given set of credentials. If the
545 This gets a reference on a live set of credentials, returning a pointer to
546 that set of credentials.
550 This gets a reference on a set of credentials that is under construction
551 and is thus still mutable, returning a pointer to that set of credentials.
559 credentials and this is attached to the file struct as 'f_cred' in place of
563 It is safe to access f_cred without the use of RCU or locking because the
564 pointer will not change over the lifetime of the file struct, and nor will the
565 contents of the cred struct pointed to, barring the exceptions listed above
575 different set of credentials. This is done in the following places: