mirror of
https://salsa.debian.org/freeipa-team/freeipa.git
synced 2024-12-24 16:10:02 -06:00
98851256f9
This also constitutes a rethinking of the token ACIs after the introduction of SELFDN support. Admins, as before, have full access to all token permissions. Normal users have read/search/compare access to all of the non-secret data for tokens assigned to them, whether managed by them or not. Users can add tokens if, and only if, they will also manage this token. Managers can also read/search/compare tokens they manage. Additionally, they can write non-secret data to their managed tokens and delete them. When a normal user self-creates a token (the default behavior), then managedBy is automatically set. When an admin creates a token for another user (or no owner is assigned at all), then managed by is not set. In this second case, the token is effectively read-only for the assigned owner. This behavior enables two important other behaviors. First, an admin can create a hardware token and assign it to the user as a read-only token. Second, when the user is deleted, only his self-managed tokens are deleted. All other (read-only) tokens are instead orphaned. This permits the same token object to be reasigned to another user without loss of any counter data. https://fedorahosted.org/freeipa/ticket/4228 https://fedorahosted.org/freeipa/ticket/4259 Reviewed-By: Jan Cholasta <jcholast@redhat.com> |
||
|---|---|---|
| .. | ||
| 10-config.update | ||
| 10-enable-betxn.update | ||
| 10-schema_compat.update | ||
| 10-selinuxusermap.update | ||
| 10-uniqueness.update | ||
| 19-managed-entries.update | ||
| 20-aci.update | ||
| 20-dna.update | ||
| 20-host_nis_groups.update | ||
| 20-indices.update | ||
| 20-nss_ldap.update | ||
| 20-replication.update | ||
| 20-syncrepl.update | ||
| 20-user_private_groups.update | ||
| 20-winsync_index.update | ||
| 21-ca_renewal_container.update | ||
| 21-replicas_container.update | ||
| 25-referint.update | ||
| 30-policy.update | ||
| 30-s4u2proxy.update | ||
| 40-automember.update | ||
| 40-delegation.update | ||
| 40-dns.update | ||
| 40-otp.update | ||
| 40-realm_domains.update | ||
| 40-replication.update | ||
| 45-roles.update | ||
| 50-7_bit_check.update | ||
| 50-dogtag10-migration.update | ||
| 50-groupuuid.update | ||
| 50-hbacservice.update | ||
| 50-ipaconfig.update | ||
| 50-krbenctypes.update | ||
| 50-lockout-policy.update | ||
| 50-nis.update | ||
| 55-pbacmemberof.update | ||
| 60-trusts.update | ||
| 61-trusts-s4u2proxy.update | ||
| 62-ranges.update | ||
| Makefile.am | ||
| README | ||
The update files are sorted before being processed because there are cases where order matters (such as getting schema added first, creating parent entries, etc). Updates are applied in blocks of ten so that any entries that are dependant on another can be added successfully without having to rely on the length of the DN to get the sorting correct. The file names should use the format #-<description>.update where # conforms to this: 10 - 19: Configuration 20 - 29: 389-ds configuration, new indices 30 - 39: Structual elements of the DIT 40 - 49: Pre-loaded data 50 - 59: Cleanup existing data 60 - 69: AD Trust 70 - 79: Reserved 80 - 89: Reserved These numbers aren't absolute, there may be reasons to put an update into one place or another, but by adhereing to the scheme it will be easier to find existing updates and know where to put new ones.