write in 30M

hc

2024-02-20 ea08eeccae9297f7aabd2ef7f0c2517ac4549acc

 kernel/Documentation/security/credentials.rst
..
..
@@ -291,7 +291,7 @@
291
291
 
292
292
  1. The reference count may be altered.
293
293
 
294
- 2. Whilst the keyring subscriptions of a set of credentials may not be
294
+ 2. While the keyring subscriptions of a set of credentials may not be
295
295
     changed, the keyrings subscribed to may have their contents altered.
296
296
 
297
297
 To catch accidental credential alteration at compile time, struct task_struct
..
..
@@ -323,7 +323,6 @@
323
323
 	uid_t current_fsuid(void)	Current's file access UID
324
324
 	gid_t current_fsgid(void)	Current's file access GID
325
325
 	kernel_cap_t current_cap(void)	Current's effective capabilities
326
-	void *current_security(void)	Current's LSM security pointer
327
326
 	struct user_struct *current_user(void)  Current's user account
328
327
 
329
328
 There are also convenience wrappers for retrieving specific associated pairs of
..
..
@@ -358,7 +357,7 @@
358
357
 Accessing Another Task's Credentials
359
358
 ------------------------------------
360
359
 
361
-Whilst a task may access its own credentials without the need for locking, the
360
+While a task may access its own credentials without the need for locking, the
362
361
 same is not true of a task wanting to access another task's credentials.  It
363
362
 must use the RCU read lock and ``rcu_dereference()``.
364
363
 
..
..
@@ -382,7 +381,7 @@
382
381
 	}
383
382
 
384
383
 Should it be necessary to hold another task's credentials for a long period of
385
-time, and possibly to sleep whilst doing so, then the caller should get a
384
+time, and possibly to sleep while doing so, then the caller should get a
386
385
 reference on them using::
387
386
 
388
387
 	const struct cred *get_task_cred(struct task_struct *task);
..
..
@@ -442,7 +441,7 @@
442
441
 held if successful.  It returns NULL if not successful (out of memory).
443
442
 
444
443
 The mutex prevents ``ptrace()`` from altering the ptrace state of a process
445
-whilst security checks on credentials construction and changing is taking place
444
+while security checks on credentials construction and changing is taking place
446
445
 as the ptrace state may alter the outcome, particularly in the case of
447
446
 ``execve()``.
448
447
 
..
..
@@ -453,9 +452,9 @@
453
452
 
454
453
 When replacing the group list, the new list must be sorted before it
455
454
 is added to the credential, as a binary search is used to test for
456
-membership.  In practice, this means :c:func:`groups_sort` should be
457
-called before :c:func:`set_groups` or :c:func:`set_current_groups`.
458
-:c:func:`groups_sort)` must not be called on a ``struct group_list`` which
455
+membership.  In practice, this means groups_sort() should be
456
+called before set_groups() or set_current_groups().
457
+groups_sort() must not be called on a ``struct group_list`` which
459
458
 is shared as it may permute elements as part of the sorting process
460
459
 even if the array is already sorted.
461
460
 
..
..
@@ -548,6 +547,10 @@
548
547
 contents of the cred struct pointed to, barring the exceptions listed above
549
548
 (see the Task Credentials section).
550
549
 
550
+To avoid "confused deputy" privilege escalation attacks, access control checks
551
+during subsequent operations on an opened file should use these credentials
552
+instead of "current"'s credentials, as the file may have been passed to a more
553
+privileged process.
551
554
 
552
555
 Overriding the VFS's Use of Credentials
553
556
 =======================================