Lines Matching full:of
18 userspace programs. Linux has a variety of actionable objects, including:
28 As a part of the description of all these objects there is a set of
29 credentials. What's in the set depends on the type of object.
33 Amongst the credentials of most objects, there will be a subset that
34 indicates the ownership of that object. This is used for resource
42 Also amongst the credentials of those objects, there will be a subset that
43 indicates the 'objective context' of that object. This may or may not be
47 The objective context is used as part of the security calculation that is
54 Most of the objects in the system are inactive: they don't act on other
65 A subject has an additional interpretation of its credentials. A subset
66 of its credentials forms the 'subjective context'. The subjective context
67 is used as part of the security calculation that is carried out when a
72 from the real UID and GID that normally form the objective context of the
77 Linux has a number of actions available that a subject may perform upon an
78 object. The set of actions available depends on the nature of the subject
88 action, and searching one or more sets of rules to see whether the subject
92 There are two main sources of rules:
96 Sometimes the object will include sets of rules as part of its
101 is an abbreviated ACL with three fixed classes of subject ('user',
102 'group' and 'other'), each of which may be granted certain privileges
105 specification of subjects, however, and so are of limited use.
107 A Linux file might also sport a POSIX ACL. This is a list of rules
112 The system as a whole may have one or more sets of rules that get
113 applied to all subjects and objects, regardless of their source.
114 SELinux and Smack are examples of this.
116 In the case of SELinux and Smack, each object is given a label as part
117 of its credentials. When an action is requested, they take the
122 Types of Credentials
125 The Linux kernel supports the following types of credentials:
134 derived from Windows). These (mostly) define the objective context of
148 - Set of permitted capabilities
149 - Set of inheritable capabilities
150 - Set of effective capabilities
164 make use of itself.
185 accesses performed by processes, without the necessity of ordinary
188 Keyrings are a special type of key. They carry sets of other keys and can
190 of keyrings:
197 cached on one of these keyrings for future accesses to find.
207 Some work by labelling the objects in a system and then applying sets of
219 When a file is opened, part of the opening task's subjective context is
221 struct to use those credentials instead of the subjective context of the task
222 that issued the operation. An example of this would be a file opened on a
223 network filesystem where the credentials of the opened file should be presented
224 to the server, regardless of who is actually doing a read or a write upon it.
231 objective security context of that file. Depending on the type of filesystem,
232 this may include one or more of the following:
242 operations allowed or disallowed as a result. In the case of execve(), the
250 In Linux, all of a task's credentials are held in (uid, gid) or through
251 (groups, keys, LSM security) a refcounted structure of type 'struct cred'.
255 Once a set of credentials has been prepared and committed, it may not be
269 6. the contents of any keyrings to which it points may be changed (the whole
270 point of keyrings being a shared set of credentials, modifiable by anyone
280 is no longer permitted to take any PID other than the one of the current
289 Once a set of credentials has been made public (by calling ``commit_creds()``
294 2. While the keyring subscriptions of a set of credentials may not be
308 to read or replace its own credentials without the need for any form of locking
316 There are convenience wrappers for retrieving specific aspects of a task's
328 There are also convenience wrappers for retrieving specific associated pairs of
335 which return these pairs of values through their arguments after retrieving
340 process's current set of credentials::
344 and functions for getting references to one of the credentials that don't
361 same is not true of a task wanting to access another task's credentials. It
383 Should it be necessary to hold another task's credentials for a long period of
389 This does all the RCU magic inside of it. The caller must call put_cred() on
393 The result of ``__task_cred()`` should not be passed directly to
396 There are a couple of convenience functions to access bits of another task's
407 should be used instead. Similarly, if multiple aspects of a task's credentials
413 Should some other single aspect of another task's credentials need to be
418 where 'member' is a non-pointer member of the cred struct. For instance::
431 alter those of another task. This means that it doesn't need to use any
435 new set of credentials by calling::
440 duplicate of the current process's credentials, returning with the mutex still
441 held if successful. It returns NULL if not successful (out of memory).
443 The mutex prevents ``ptrace()`` from altering the ptrace state of a process
445 as the ptrace state may alter the outcome, particularly in the case of
449 checks and hooks done. Both the current and the proposed sets of credentials
458 is shared as it may permute elements as part of the sorting process
466 This will alter various aspects of the credentials and the process, giving the
470 will notify the scheduler and others of the changes.
473 end of such functions as ``sys_setresuid()``.
478 Furthermore, once this function has been called on a new set of credentials,
521 This releases a reference to the given set of credentials. If the
527 This gets a reference on a live set of credentials, returning a pointer to
528 that set of credentials.
532 This gets a reference on a set of credentials that is under construction
533 and is thus still mutable, returning a pointer to that set of credentials.
540 credentials and this is attached to the file struct as ``f_cred`` in place of
545 It is safe to access ``f_cred`` without the use of RCU or locking because the
546 pointer will not change over the lifetime of the file struct, and nor will the
547 contents of the cred struct pointed to, barring the exceptions listed above
552 instead of "current"'s credentials, as the file may have been passed to a more
555 Overriding the VFS's Use of Credentials
560 different set of credentials. This is done in the following places: