Searched full:permission (Results 1 – 25 of 87) sorted by relevance
1234
| /Documentation/arch/x86/ |
| D | xstate.rst | 49 has permission in userspace storage of type uint64_t. The second argument
56 ARCH_REQ_XCOMP_PERM allows to request permission for a dynamically enabled
63 When requesting permission for a feature, the kernel checks the
72 Permission, when granted, is valid per process. Permissions are inherited
77 permission to use the feature. If the process has no permission then the
78 kernel sends SIGILL to the application. If the process has permission then
123 explicitly ask permission to use it::
150 The permission for the guest state component needs to be managed separately
152 are extended to control the guest permission:
167 same semantics for the guest permission. While providing a similar
[all …]
|
| /Documentation/filesystems/ |
| D | adfs.rst | 39 ownmask=nnn The permission mask for ADFS 'owner' permissions
41 othmask=nnn The permission mask for ADFS 'other' permissions
58 (In older versions, an 'execute' permission did exist, but this
59 does not hold the same meaning as the Linux 'execute' permission
92 You can therefore tailor the permission translation to whatever you
|
| D | affs.rst | 57 permission if the corresponding r bit is set.
133 - r permission will allow R for user, group and others.
135 - w permission will allow W for user, group and others.
137 - x permission of the user will allow E for plain files.
|
| D | vfat.rst | 28 The permission mask (for files and directories, see *umask(1)*).
32 The permission mask for the directory.
36 The permission mask for files.
40 This option controls the permission check of mtime/atime.
160 If set, the execute permission bits of the file will be
|
| D | path-lookup.txt | 247 | name: "/" | inode's permission, and then look up the next
345 routine requiring rcu drop, permission for permission check requiring drop,
348 rcu-lookups restart nodentry link revalidate permission
|
| /Documentation/security/keys/ |
| D | core.rst | 44 to it, subject to permission checking.
223 only recurse into nested keyrings that have search permission set.
228 keyring to a key, a process must have Write permission on the keyring and
229 Link permission on the key.
246 as well; SELinux is simply invoked after all basic permission checks have been
253 creation request. Tasks must be granted explicit permission to assign a
254 particular context to newly-created keys, using the "create" permission in the
284 The only keys included in the list are those that grant View permission to
389 type. The process must also have permission to write to the key to be able
396 does not have permission to write to the keyring.
[all …]
|
| D | request-key.rst | 156 if this denies permission, it doesn't search further.
166 grants permission, it recurses, executing steps (2) and (3) on that
169 The process stops immediately a valid key is found with permission granted to
207 the basal keyring does not grant Search permission.
|
| /Documentation/userspace-api/media/ |
| D | gen-errors.rst | 72 - Permission denied. Can be returned if the device needs write
73 permission, or some special capabilities is needed (e. g. root)
|
| D | fdl-appendix.rst | 206 the original publisher of that version gives permission.
231 giving the public permission to use the
262 original publisher of the version it refers to gives permission.
309 replace the old one, on explicit permission from the previous publisher
313 do not by this License give permission to use their names for publicity
395 special permission from their copyright holders, but you may include
451 Permission is granted to copy, distribute and/or modify this
|
| D | index.rst | 46 Permission is granted to copy, distribute and/or modify this document
|
| /Documentation/security/ |
| D | SCTP.rst | 38 service as shown in the permission check tables below.
234 | BIND Permission Checks |
243 | CONNECT Permission Checks |
292 SELinux SCTP support adds the ``name_connect`` permission for connecting
293 to a specific port type and the ``association`` permission that is explained
308 ``association`` permission be validated. This is validated by checking the
|
| /Documentation/devicetree/bindings/soc/mediatek/ |
| D | devapc.yaml | 8 title: MediaTek Device Access Permission Control driver
|
| /Documentation/trace/coresight/ |
| D | coresight-dummy.rst | 14 have permission to access or configure, e.g., CoreSight TPDMs on Qualcomm
|
| /Documentation/sphinx/ |
| D | kerneldoc.py | 5 # Permission is hereby granted, free of charge, to any person obtaining a
12 # The above copyright notice and this permission notice (including the next
|
| /Documentation/userspace-api/gpio/ |
| D | error-codes.rst | 55 - Permission denied. Typically returned in response to an attempt
|
| /Documentation/devicetree/bindings/arm/ |
| D | arm,coresight-dummy-source.yaml | 18 devices kernel don't have permission to access or configure. For some SOCs,
|
| D | arm,coresight-dummy-sink.yaml | 18 kernel don't have permission to access or configure, e.g., CoreSight EUD on
|
| /Documentation/userspace-api/media/v4l/ |
| D | func-open.rst | 62 The caller has no permission to access the device.
|
| /Documentation/scsi/ |
| D | LICENSE.FlashPoint | 48 permission.
|
| /Documentation/admin-guide/ |
| D | mono.rst | 69 If this fails with a permission denied error, check
|
| /Documentation/mm/ |
| D | hmm.rst | 219 permission, it sets::
225 in the range with at least read permission.
228 which it wants to have write permission. Now driver set::
236 write permission i.e., if the CPU pte does not have write permission set then HMM
|
| /Documentation/process/ |
| D | code-of-conduct.rst | 36 address, without explicit permission
|
| /Documentation/usb/ |
| D | usbdevfs-drop-permissions.c | 87 "[3] Narrow interface permission mask\n" in main()
|
| /Documentation/userspace-api/media/dvb/ |
| D | frontend_f_open.rst | 91 - The caller has no permission to access the device.
|
| /Documentation/ABI/stable/ |
| D | firewire-cdev | 49 userland implement different access permission models, some
|
1234