From e55ce1d6bffa943b13b669050609ce8d2f793fb0 Mon Sep 17 00:00:00 2001 From: René Genz Date: Oct 22 2017 15:38:59 +0000 Subject: Fix spelling mistakes; fix 2 links --- diff --git a/design_pages/accounts_service.rst b/design_pages/accounts_service.rst index 8fa789b..75bf25e 100644 --- a/design_pages/accounts_service.rst +++ b/design_pages/accounts_service.rst @@ -435,7 +435,7 @@ interface name. - **ADD** **method** FindGroupByIdInDomain(String domain, Int64 id) - *id*: the group's GID - - *domain*: the groups's domain name + - *domain*: the group's domain name - returns: Path *group*: the path for the group object - Error *org.freedesktop.Accounts.Error.Failed*: no such group exists @@ -451,7 +451,7 @@ interface name. name) - *name*: the group's name - - *domain*: the groups's domain name. + - *domain*: the group's domain name. - returns: Path *group*: the path for the group object - Error *org.freedesktop.Accounts.Error.Failed*: no such group exists diff --git a/design_pages/active_directory_access_control.rst b/design_pages/active_directory_access_control.rst index a67536f..d848812 100644 --- a/design_pages/active_directory_access_control.rst +++ b/design_pages/active_directory_access_control.rst @@ -20,7 +20,7 @@ Somewhat related: Problem Statement ----------------- -The recommended way of connecting a Linux client to an Active Directory +The recommended way of connecting a GNU/Linux client to an Active Directory domain is using the `AD provider `__. However, in the default configuration of the Active Directory provider, @@ -38,7 +38,7 @@ Current access control options ------------------------------ With the existing SSSD, the administrator has two basic means to -restrict access control to the Linux client - using the `simple access +restrict access control to the GNU/Linux client - using the `simple access control provider `__ or configuring the LDAP access control provider. Each approach has its @@ -67,7 +67,7 @@ named ``tux`` and group called ``linuxadmins``. :: - Cons: - Account expiration is not checked - - Limited expresiveness. No way to combine several clauses + - Limited expressiveness. No way to combine several clauses - Does not align with the LDAP structure the Active Directory uses Using the LDAP access provider @@ -118,13 +118,13 @@ Proposed solution The proposal is to add a new access filter configuration option to the existing AD access provider. Adding the option to the AD provider would greatly simplify the configuration when compared to the LDAP access -control, while maintaining the full expresiveness of +control, while maintaining the full expressiveness of ``ldap_access_filter``. The new option would be called ``ad_access_filter``. If the new option was set, then the AD access provider would first match the entry against the filter in that option. If the entry matched, then the account would be checked for expiration. -The following exapmple illustrates an example similar to the one above, +The following example illustrates an example similar to the one above, using the proposed AD options: :: access_provider = ad @@ -260,7 +260,7 @@ How to test denied access - this test must include users from the primary domain as well as a sub domain - - Different filters should be tested to make sure the most speficic + - Different filters should be tested to make sure the most specific filter applies - example: add a restrictive filter for dom1 and permissive diff --git a/design_pages/active_directory_dns_updates.rst b/design_pages/active_directory_dns_updates.rst index 7e93f5c..c1c6fa5 100644 --- a/design_pages/active_directory_dns_updates.rst +++ b/design_pages/active_directory_dns_updates.rst @@ -82,7 +82,7 @@ following reasons: - the computer is restarted - the DHCP lease is renewed -- periodicaly every 24 hours by default +- periodically every 24 hours by default - this is configurable in the windows registry using the ``DefaultRegistrationRefreshInterval`` key under the @@ -305,7 +305,7 @@ How to test - The other client's DNS records should remain intact in the DNS MMC console -Links and recources +Links and resources ------------------- - `Understanding aging and diff --git a/design_pages/active_directory_fixed_dns_site.rst b/design_pages/active_directory_fixed_dns_site.rst index 854efa5..fba65e6 100644 --- a/design_pages/active_directory_fixed_dns_site.rst +++ b/design_pages/active_directory_fixed_dns_site.rst @@ -17,7 +17,7 @@ Use cases --------- The site discovery relies on client being part of subnet. It is not -always practical or even possible to assign Linux machines to the right +always practical or even possible to assign GNU/Linux machines to the right subnet. Still, these clients should be able to leverage the nearest AD site, even at the expense of manual configuration in ``sssd.conf``. diff --git a/design_pages/active_directory_gpo_integration.rst b/design_pages/active_directory_gpo_integration.rst index 10cf37c..09b79e2 100644 --- a/design_pages/active_directory_gpo_integration.rst +++ b/design_pages/active_directory_gpo_integration.rst @@ -37,7 +37,7 @@ Windows Logon Rights, with each set classified by its logon method (e.g. interactive, remote interactive) and consisting of a whitelist [and blacklist] of users and groups that are allowed [or denied] access to the computer using the set's logon method. In order to integrate Windows -Logon Rights into a Linux environment, we allow pam service names to be +Logon Rights into a GNU/Linux environment, we allow pam service names to be mapped to a specific Logon Right. We provide default mappings for all of the commonly used pam service names, but we also allow the admin to add/remove mappings as needed (to support custom pam service names, for @@ -108,11 +108,11 @@ A client-side implementation consists of the following components: that contain the "Security Settings" CSE, which it feeds, one by one, to the SMB/CIFS Engine - SMB/CIFS Engine: makes blocking libsmbclient calls to retrieve each - GPO's GPT.INI and GptTmpl.inf files, and stores the files in the gpo + GPO's GPT.INI and GptTmpl.inf files, and stores the files in the GPO cache (/var/lib/sss/gpo\_cache), from which the GPO Enforcement Engine will retrieve them - GPO Enforcement Engine: enforces GPO-based access control by - retrieving each GPO's policy file (GptTmpl.inf) from the gpo cache, + retrieving each GPO's policy file (GptTmpl.inf) from the GPO cache, parsing it, and making an access control decision by comparing the user/groups against the whitelist/blacklist of the Logon Right of interest (which is based on the pam service name) @@ -135,7 +135,7 @@ Rather, a new "ad\_gpo\_access\_control" config option is provided which can be set to "disabled" (neither evaluated nor enforced), "enforcing" (evaluated and enforced), or "permissive" (evaluated, but not enforced).The "permissive" value is the default, primarily to facilitate -a smooth transition for administrators; it evalutes the gpo-based access +a smooth transition for administrators; it evaluates the GPO-based access control rules and outputs a syslog message if access would have been denied. By examining the logs, administrators can then make the necessary changes before setting the mode to "enforcing". @@ -186,7 +186,7 @@ GPO Retrieval there is no cached version) - Retrieves the policy file corresponding to the GPO - (GptTmpl.inf) and saves it to the gpo cache + (GptTmpl.inf) and saves it to the GPO cache (/var/lib/sss/gpo\_cache) - Returns the fresh version to the backend, which stores it in the cache @@ -201,7 +201,7 @@ GPO Enforcement - For each GPO - Retrieves GPO's corresponding policy file (i.e. GptTmpl.inf) - file from gpo cache + file from GPO cache - Parses policy file, extracting entries corresponding to the Logon Right of interest (determined by the pam service name) - Enforces access control policy settings @@ -247,9 +247,9 @@ Although we are only implementing a computer-based GPO in the first implementation, we should keep in mind that user-based GPOs could have a different refresh interval. As such, we would need to add a new configuration option ("computer\_gpo\_refresh\_interval") to the -existing AD access provider that would specify the gpo retrieval refresh +existing AD access provider that would specify the GPO retrieval refresh interval in seconds. This would specify the period to use in the -periodic task API to determine how often to call the gpo retrieval code. +periodic task API to determine how often to call the GPO retrieval code. By default, Microsoft sets this value to 90 minutes. It is an open issue as to whether we want to support the random offset interval or the ability to disable refresh altogether. @@ -279,7 +279,7 @@ the following times: retrieval takes place when returning to online mode from offline mode. This really depends on what we decide about the first two retrieval times above. If we aren't doing periodic refresh, and are - only retrieving gpo's at login time, then an online callback might + only retrieving GPOs at login time, then an online callback might not be needed. If we are doing periodic refresh, then we can set the "offline" parameter of be\_ptask\_create(...) to DISABLE (which means the task is disabled immediately when back end goes offline and then @@ -298,7 +298,7 @@ at periodic intervals? do here? If we wanted to log out the user, do we have an existing mechanism to do this? -If we implement gpo refresh, which of the refresh configuration options +If we implement GPO refresh, which of the refresh configuration options should we implement and how? - sssd configuration options @@ -311,16 +311,16 @@ should we implement and how? - disable\_gpo\_refresh (default false)? Presumably, this would be done so that performance would not be adversely affected during the logon session. Alternatively, we could tell admins that wanted - to disable gpo refresh to set the + to disable GPO refresh to set the entry\_cache\_computer\_gpo\_timeout to zero (0), although this would not be how Microsoft interprets a zero value. Does sssd interpret '0' as "disable" elsewhere? -- gpo refresh interval GPO +- GPO refresh interval GPO - if we didn't want to clutter sssd's configuration namespace, we could just use the standard Microsoft GPO that allows an admin to - specify the aforementioend refresh intervals (and distribute a + specify the aforementioned refresh intervals (and distribute a consistent configuration to a set of computers) Options @@ -357,7 +357,7 @@ intervals. - suffers performance hit at initial startup and then periodically - policy data likely to be stale - requires implementation of periodic refresh, including refresh - configuration (for which we should probably use gpo refresh GPO) + configuration (for which we should probably use GPO refresh GPO) Recommendation -------------- @@ -459,7 +459,7 @@ How to test - Test ad\_gpo\_cache\_timeout config option - - perform standard test with a sysdb cache with no gpo entries (or a + - perform standard test with a sysdb cache with no GPO entries (or a clean sysdb cache) - make a change to a GPO policy setting so that the sysvol\_gpt\_version is incremented diff --git a/design_pages/async_winbind.rst b/design_pages/async_winbind.rst index 0c5ea4e..0212fa7 100644 --- a/design_pages/async_winbind.rst +++ b/design_pages/async_winbind.rst @@ -76,7 +76,7 @@ not) when the WinBind provider starts. In other words, there will be 3 settings: -**Mimimum** number of worker processes **running**. +**Minimum** number of worker processes **running**. **Maximum** number of worker processes **running**. diff --git a/design_pages/autofs_integration.rst b/design_pages/autofs_integration.rst index a2b8d6e..82d5343 100644 --- a/design_pages/autofs_integration.rst +++ b/design_pages/autofs_integration.rst @@ -10,7 +10,7 @@ page summarizes the discussions and design. Autofs is able to look up maps stored in LDAP. However, autofs does all the lookups on its own. Even though autofs uses the ``nsswitch.conf`` configuration file, there is no glibc interface such as those for -retreiving users and groups and by extension no nscd caching. +retrieving users and groups and by extension no nscd caching. The benefits of the integration would be: @@ -50,7 +50,7 @@ autofs. The lookup modules are named ``/lookup_.so`` where ```` is the source name from the "automount:" line of -``/etc/nssswitch.conf``. So the SSSD lookup module would be named +``/etc/nsswitch.conf``. So the SSSD lookup module would be named ``lookup_sss.so`` and selected in nsswitch.conf with the directive ``automount: files sss`` (to allow for local client overrides) or just ``automount: sss``. @@ -66,7 +66,7 @@ libnss\_sss.so and dlsym() the functions needed. The API provided by SSSD ------------------------ -The SSSD API would live in libnsss\_sss.so. That means polluting the +The SSSD API would live in libnss\_sss.so. That means polluting the library a little with functions that are not strictly name-service-switch related, but would allow us to reuse a fair amount of code and talk to the NSS responder socket easily. @@ -213,8 +213,8 @@ Fully Qualified Names ^^^^^^^^^^^^^^^^^^^^^ With user/group lookups, the domain can be specified by using a -"fully-qualified-name", for example getent passwd -`jhrozek@redhat.com `__. We should support +"fully-qualified-name", for example ``getent passwd +jhrozek@redhat.com``. We should support something similar with autofs. However, maps can include any characters that are valid for filesystem path names, including '@', so there's a potential conflict. @@ -225,11 +225,11 @@ potential conflict. - FQDN requests will be allowed by default, but not required unless ``use_fully_qualified_names`` is set to TRUE - The FQDN name-domain separator is @ by default, but SSSD allows it to - be configurable even in the current using the ``re_expression`` + be configurable even in the current version using the ``re_expression`` parameter. -Future and miscellanous work -~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Future and miscellaneous work +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The first iteration will aim at providing a working autofs integration for generic LDAP servers. There is a number of tasks that might not make diff --git a/design_pages/backend_dns_helpers.rst b/design_pages/backend_dns_helpers.rst index 9dfcd6e..63450f2 100644 --- a/design_pages/backend_dns_helpers.rst +++ b/design_pages/backend_dns_helpers.rst @@ -51,7 +51,7 @@ We need a few basic methods to start: will be used by all. 2. A secondary implementation method that provides a DNS domain and the - request to resolve SRV records instead of (or in addtion to) + request to resolve SRV records instead of (or in addition to) providing a list of servers:services. The helper will decide when it is time to refresh the SRV list. diff --git a/design_pages/blank_template.rst b/design_pages/blank_template.rst index 3de78f6..1fdc00d 100644 --- a/design_pages/blank_template.rst +++ b/design_pages/blank_template.rst @@ -33,7 +33,7 @@ Implementation details ---------------------- A more technical extension of the previous section. Might include low-level details, such as C structures, function synopsis etc. In case of very -trivial features (e.g a new option), this section can be merged with the +trivial features (e.g. a new option), this section can be merged with the previous one. Configuration changes diff --git a/design_pages/config_enhancements.rst b/design_pages/config_enhancements.rst index 9efe251..5a73fec 100644 --- a/design_pages/config_enhancements.rst +++ b/design_pages/config_enhancements.rst @@ -45,7 +45,7 @@ Use cases - Config validation - - prerequisity: have a common definition of options and autogenerate + - prerequisite: have a common definition of options and autogenerate the rest - Autogenerate dp\_opts, man pages and configAPI sources from a @@ -77,7 +77,7 @@ Implementation details A more technical extension of the previous section. Might include low-level details, such as C structures, function synopsis etc. In case -of very trivial features (e.g a new option), this section can be merged +of very trivial features (e.g. a new option), this section can be merged with the previous one. Configuration changes diff --git a/design_pages/data_provider.rst b/design_pages/data_provider.rst index 70512e1..c2cf5df 100644 --- a/design_pages/data_provider.rst +++ b/design_pages/data_provider.rst @@ -11,7 +11,7 @@ Problem statement ----------------- Current state of data provider interface is not extensible enough to -fulfil needs of planned SSSD features such as `SSSD Status Tool +fulfill needs of planned SSSD features such as `SSSD Status Tool `__. The main flaw that we aim to solve is to simplify adding of new methods, properties and possibly signals using our *sbus* interface. As a side @@ -117,7 +117,7 @@ Goals to achieve - make adding a new target automated and error proof - make adding a new method automated and error proof - create a proper talloc hierarchy so we can control clean up process -- support module's contructor and private data shared across target's +- support module's constructor and private data shared across target's initialization functions - make method handlers pure tevent requests that returns single error code @@ -141,7 +141,7 @@ parsing may be left to handler implementation*. In the handler, we process parameters and *create a data provider request*. This request will call a data provider method handler which is a basic **tevent request**. When the request is finished, data provider tevent callback -is invoked and it send a reply back to the responder. Depenging on the +is invoked and it send a reply back to the responder. Depending on the request result the reply message may be either error, sending an error code and message, or success where a default or *custom \_recv* function may be called to obtain and send additional attributes. @@ -156,7 +156,7 @@ or data provider at all. The data flow looks like this: :: ... asynchronous processing ... (tevent done) -> (dp request done) -> (error detected) -> (dbus error) -> Responder - -> (success) -> (recive callback) -> (dbus) -> Reponder + -> (success) -> (receive callback) -> (dbus) -> Responder Data Provider Initialization ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ @@ -164,7 +164,7 @@ Data Provider Initialization This section describes what is needed to initialize data provider. It talks only about sections that may change in the future in order to extend SSSD's functionality, it does not describe how it works under the -hood. The initializion basically consist of these steps: +hood. The initialization basically consist of these steps: **1. Initialization of data provider modules and targets** @@ -224,8 +224,8 @@ interface into the data provider. #. Add new method (or interface) into data provider introspection file **dp\_iface.xml** #. Register this interface or method in **dp\_iface.c** by providing the - interface structure generated from the instrospection file and - ammending **dp\_map** array + interface structure generated from the introspection file and + amending **dp\_map** array #. (optionally if needed) Add new data provider method and/or target into **enum dp\_methods** and **enum dp\_targets** respectively #. Implement the method handler @@ -305,7 +305,7 @@ following headers: :: All parameters except memory context are combined into one structure to simplify possible future extensions (thus when a new parameter needs to be added we don't have to modify existing handler). The *data* in -recieve function may be used to pass output parameters into the D-Bus +receive function may be used to pass output parameters into the D-Bus reply. For example, the following reply callback simulates current reply message which returns major and minor error together with error message. :: @@ -343,7 +343,7 @@ On memory hierarchy ~~~~~~~~~~~~~~~~~~~ The memory hierarchy is known strictly specified and should not be -broken. It gives us the ability to cleary clean up all data provider +broken. It gives us the ability to clearly clean up all data provider data on SSSD exit. :: struct be_ctx @@ -402,7 +402,7 @@ Each data provider request life cycle can be tracked in debug logs with a special message prefix: **DP Request [$name #$index]**. The $name is the name of the request (i.e. which method was called), $index is a cyclic number assigned to the request. When we run out of number we -siply start from 1 again. +simply start from 1 again. In the debugger we can monitor active data provider request, clients, modules and targets in **be\_ctx->provider**. diff --git a/design_pages/dbus_domains.rst b/design_pages/dbus_domains.rst index 46d7a1f..746b147 100644 --- a/design_pages/dbus_domains.rst +++ b/design_pages/dbus_domains.rst @@ -87,11 +87,11 @@ Properties - **property** Uint32 min\_id - - Minimum uid and gid value for this domain + - Minimum UID and GID value for this domain - **property** Uint32 max\_id - - Maximum uid and gid value for this domain + - Maximum UID and GID value for this domain - **property** String realm @@ -111,7 +111,7 @@ Properties - **property** Boolean enumerable - - Whether this domain can be enumarated or not + - Whether this domain can be enumerated or not - **property** Boolean use\_fully\_qualified\_names diff --git a/design_pages/dbus_responder.rst b/design_pages/dbus_responder.rst index 9ea8c2d..3de4da4 100644 --- a/design_pages/dbus_responder.rst +++ b/design_pages/dbus_responder.rst @@ -37,7 +37,7 @@ The DBus interface design This section gathers feedback expressed in mailing lists, private e-mail conversations and IRC discussions and summarizes feature requests and areas that need improvement into a design proposal of both the DBus API -and several required changes in the core SSSD deamon. +and several required changes in the core SSSD daemon. Cached objects ~~~~~~~~~~~~~~ @@ -50,7 +50,7 @@ Object exposed on the bus Instead of a single interface returning object attributes in an LDAP-like way, the interface would be built in an object-oriented -fashion. Each object (ie a user or a group) would be identified with an +fashion. Each object (i.e. a user or a group) would be identified with an object path and methods would be available to the interface user to make it possible to retrieve either a single object or a set of object. @@ -122,7 +122,7 @@ org.freedesktop.sssd.infopipe.Components interface, which is define as: - *debug\_level*: Debug level to set - returns: nothing - note: changes will be permanent but do not require restart of the - deamon + daemon - **property** String name @@ -221,11 +221,11 @@ only properties and not methods are considered: - **property** Uint32 min\_id - - Minimum uid and gid value for this domain + - Minimum UID and GID value for this domain - **property** Uint32 max\_id - - Maximum uid and gid value for this domain + - Maximum UID and GID value for this domain - **property** String realm @@ -245,7 +245,7 @@ only properties and not methods are considered: - **property** Boolean enumerable - - Whether this domain can be enumarated or not + - Whether this domain can be enumerated or not - **property** Boolean use\_fully\_qualified\_names @@ -268,16 +268,16 @@ experiment with. Synchronous getter behaviour ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Retrieving a property with a getter will always be sychronous and return +Retrieving a property with a getter will always be synchronous and return the value currently cached. The getter might schedule an out-of-band update depending on the state of the cache object. The primary reason for the getter being synchronous is to be able to be composable, in other words being able to call N getters in a loop and construct a reply -message containing N properties without resorting to asychronous updates +message containing N properties without resorting to asynchronous updates of the properties. Callers that with to have an up-to-date view of the properties should -update the object by calling a special ``update`` (not included atm) +update the object by calling a special ``update`` (not included ATM) method or subscribe to the PropertiesChanged interface. SSSD daemon features @@ -311,7 +311,7 @@ The responder will have a whitelist of attributes that the client can query. No other attributes will be returned. Requesting an attribute that is not permitted will yield an empty response, same as if the attribute didn't exist. The whitelist will include the standard set of -POSIX attributes as returned by ie ``getpwnam`` by default. +POSIX attributes as returned by i.e. ``getpwnam`` by default. The administrator will be allowed to extend the whitelist in sssd.conf using a configuration directive either in the ``[ifp]`` section itself diff --git a/design_pages/dbus_signal_property_changed.rst b/design_pages/dbus_signal_property_changed.rst index 729e563..cd410cf 100644 --- a/design_pages/dbus_signal_property_changed.rst +++ b/design_pages/dbus_signal_property_changed.rst @@ -106,7 +106,7 @@ How To Test #. Hook onto *PropertiesChanged* signal, e. g. with *dbus-monitor'̈́'* #. Trigger change of user/group -#. Signal should be recieved +#. Signal should be received Questions ~~~~~~~~~ diff --git a/design_pages/dbus_simple_api.rst b/design_pages/dbus_simple_api.rst index 18856a1..c01b5ea 100644 --- a/design_pages/dbus_simple_api.rst +++ b/design_pages/dbus_simple_api.rst @@ -15,7 +15,7 @@ Using D-Bus requires a significant amount of knowledge of D-Bus and its underlying library API. Libraries like libdbus or libdbus\_glib are quite complex and requires a lot of code to do even the simplest things. The purpose of this document is to describe a new public API to access -most fundamental parts of SSSD's D-Bus repsonder in a simple way so that +most fundamental parts of SSSD's D-Bus responder in a simple way so that a user doesn't have to deal with D-Bus at all. Prerequisites diff --git a/design_pages/dbus_users_and_groups.rst b/design_pages/dbus_users_and_groups.rst index 424c44e..cca686e 100644 --- a/design_pages/dbus_users_and_groups.rst +++ b/design_pages/dbus_users_and_groups.rst @@ -184,7 +184,7 @@ Properties - u gidNumber - - The groups's primary GID. + - The group's primary GID. - ao users @@ -210,7 +210,7 @@ limit set in sssd.conf with a new configuration option **filter\_limit**. This option can be present in [ifp] and [domain] sections to set this limit for data provider filter searches ([domain] section) and also global hard limit for the listing methods itself -([ifp] section). This limit is supposed to improve performace with large +([ifp] section). This limit is supposed to improve performance with large databases so we process only a small number of records. If the option is set to 0, the limit is disabled. @@ -219,7 +219,7 @@ not support complete set of regular expressions. The asterisk can be present on the beginning of the filter '\*filter', its end 'filter\*', both sides '\*filter\*' or even in the middle '\*fil\*ter\*', since it is supported by both LDAP and LDB. However, only prefix-filter -('filter\*'), can take the performace boost from indices so other filter +('filter\*'), can take the performance boost from indices so other filter may not perform so good with huge databases. Configuration changes diff --git a/design_pages/ddns_messages_update.rst b/design_pages/ddns_messages_update.rst index 3834ac8..258dfd5 100644 --- a/design_pages/ddns_messages_update.rst +++ b/design_pages/ddns_messages_update.rst @@ -17,7 +17,7 @@ address families might be prohibited to be changed on server. Use cases ~~~~~~~~~ -If DNS system is broken using dyndns\_server option might be an +If DNS system is broken using dyndns\_server option might be a workaround Overview of the solution diff --git a/design_pages/fast_nss_cache.rst b/design_pages/fast_nss_cache.rst index 90165d6..979c95b 100644 --- a/design_pages/fast_nss_cache.rst +++ b/design_pages/fast_nss_cache.rst @@ -26,12 +26,12 @@ processed by sssd\_nss, read() the reply back. Because sssd\_nss may be busy answering many requests a queue may build up and replies be delayed. -Allowing the clinets to direcly access SSSD caches is not possible for +Allowing the clients to directly access SSSD caches is not possible for various reasons including: - sssd uses LDB as caching backend and LDB depends on byte range locks. - Letting a client read access to the cache would allow DoS if the - client lcoks a record and never unlock it. + Giving a client read access to the cache would allow DoS, f.e. the + client locks a record and never unlocks it. - sssd stores data not all clients are allowed to get access to (password hashes for example) and partitioning access to this data within the LDB cache is not feasible. @@ -63,7 +63,7 @@ to memory and do not suffer from any context switch. They also happen in parallel within each process with synchronization (in order to allow updates) performed by using memory barriers. -Cache files can only be used for direct lookups (by name or by uid/gid), +Cache files can only be used for direct lookups (by name or by UID/GID), enumerations are \_never\_ handled via fast cache lookups by design, they always fallback to socket communication. @@ -74,11 +74,11 @@ accessible read-only by clients. Configuration ------------- -At the moement we plan to provide 3 parameters per map that can control +At the moment we plan to provide 3 parameters per map that can control the caches. -- Per map enablement parameter that allows to activate/deactiveate maps - invidiually. +- Per map enablement parameter that allows to activate/deactivate maps + individually. - Per map cache size to fine tune the cache sizes in case space is at a premium or the dataset does not fit the default cache. - Expiration time for entries. diff --git a/design_pages/files_provider.rst b/design_pages/files_provider.rst index 2ae4191..8a227e4 100644 --- a/design_pages/files_provider.rst +++ b/design_pages/files_provider.rst @@ -161,7 +161,7 @@ scenarios: #. Failover from ``sss`` to ``files`` when SSSD is not running - this is the 'worst' case where ``sss`` is enabled in ``nsswitch.conf`` but - the deamon is not running at all, so the system falls back from + the daemon is not running at all, so the system falls back from ``sss`` to ``files`` for user lookups. - Single lookup :: @@ -176,7 +176,7 @@ scenarios: _nss_files_getpwnam cnt:100 avg:19 min:16 max:42 sum:1907 us _nss_sss_getpwnam cnt:100 avg:22 min:19 max:74 sum:2248 us -#. Round-trip between SSSD deamon's populated cache and OS when the +#. Round-trip between SSSD daemon's populated cache and OS when the memory cache is not used or not populated - Single lookup :: diff --git a/design_pages/fleet_commander_integration.rst b/design_pages/fleet_commander_integration.rst index 1fa01df..f01353f 100644 --- a/design_pages/fleet_commander_integration.rst +++ b/design_pages/fleet_commander_integration.rst @@ -34,7 +34,7 @@ in FreeIPA. Overview of the solution ------------------------ FleetCommander consists on two components: - * a Cockpit plugin that connects to the freeIPA and sets up profiles + * a Cockpit plugin that connects to the FreeIPA and sets up profiles for different users. * a client side component activated by SSSD, which applies all the profiles retrieved by the latter. @@ -78,7 +78,7 @@ similar to how we process sudo or HBAC rules. The local search's filter will look for the user and all his groups. For performance reasons, we need to check if initgroups was performed prior to looking up the profiles and only issue another initgroups request if the user entry's -inigroup timestamp is expired. +initgroup timestamp is expired. The profiles will also be stored in the cache to allow offline processing. As an additional enhancement, we can skip writing the diff --git a/design_pages/global_catalog_lookups.rst b/design_pages/global_catalog_lookups.rst index 5594315..685783c 100644 --- a/design_pages/global_catalog_lookups.rst +++ b/design_pages/global_catalog_lookups.rst @@ -114,7 +114,7 @@ How to test Since the Global Catalog lookups just replace the current lookup methods SSSD should just behave as before (Regression testing). -Additional the following changes might be visible on the user or admind +Additionally the following changes might be visible on the user or admin level. AD provider diff --git a/design_pages/idmap_auto_assign_new_slices.rst b/design_pages/idmap_auto_assign_new_slices.rst index 4f38bf7..917503e 100644 --- a/design_pages/idmap_auto_assign_new_slices.rst +++ b/design_pages/idmap_auto_assign_new_slices.rst @@ -31,7 +31,7 @@ change. SIDs can be mapped to different UIDs and UIDs might be mapped on different SIDs or at no SIDs at all. For example Active Directory users might not be able to access their -files on UNIX hosts any more as the files would belong to their formal +files on UNIX hosts any more as the files would belong to their former UNIX IDs not the current ones. After this feature is implemented administrator's action will not be @@ -60,7 +60,7 @@ Update algorithm for mapping SID to UNIX ID: domains that SID belongs to. - If such list is not empty then check if SID matches against secondary ranges of these domains and perform similar computation of UNIX ID as - is done for primary slices. If SID is not in helper ranges new range + is done for primary slices. If SID is not in helper ranges a new range is generated and its identifier string is *domain\_sid-$first\_rid* where $first\_rid is **((int)(RIDofSID / range\_size)) \* range\_size**. @@ -79,8 +79,8 @@ Implementation details Introduce new struct **idmap\_range\_params** that holds all relevant information for slice ranges, such as: -- uint32\_t min\_id - minimal unix ID in given slice -- uint32\_t max\_id - maximal unix ID in given slice +- uint32\_t min\_id - minimal UNIX ID in given slice +- uint32\_t max\_id - maximal UNIX ID in given slice - char \*range\_id - uint32\_t first\_rid diff --git a/design_pages/integrate_sssd_with_cifs_client.rst b/design_pages/integrate_sssd_with_cifs_client.rst index 2c19d13..e68f874 100644 --- a/design_pages/integrate_sssd_with_cifs_client.rst +++ b/design_pages/integrate_sssd_with_cifs_client.rst @@ -20,7 +20,7 @@ Designs and tickets this design (might) depend: Problem Statement ~~~~~~~~~~~~~~~~~ -Although mapping of Posix UIDs and SIDs is not needed mounting a CIFS +Although mapping of POSIX UIDs and SIDs is not needed mounting a CIFS share it might become necessary when working with files on the share, e.g. when modifying ACLs. Up to version 5.8 the cifs-utils package uses Winbind for this exclusively and the following binaries were linked @@ -32,7 +32,7 @@ against libwbclient: With version 5.9 of cifs-utils a plugin interface was introduced by Jeff Layton (Thank you very much Jeff) to allow services other than winbind -to handle the mapping of Posix UIDs and SIDs. SSSD will provide a plugin +to handle the mapping of POSIX UIDs and SIDs. SSSD will provide a plugin to allow the cifs-utils to ask SSSD to map the ID. With this plugin an SSSD client can access a CIFS share with the same functionality as a client running Winbind. @@ -71,7 +71,7 @@ section is included below. ID mapping calls. Although it might be possible possible to map IDs algorithmically without talking to SSSD I think those calls should also reach out to SSSD to do the mapping. The main reason is to allow - other kind of mappings (e.g. using Posix attributes if available in + other kind of mappings (e.g. using POSIX attributes if available in AD). :: 57 /* @@ -143,7 +143,7 @@ section is included below. 123  * cifs_idmap_sids_to_ids - convert struct cifs_sids to struct cifs_uxids 124  * @handle - context handle 125  * @sid    - pointer to array of struct cifs_sids to be converted - 126  * @num    - number of sids to be converted + 126  * @num    - number of SIDs to be converted 127  * @cuxid  - pointer to preallocated array of struct cifs_uxids for return 128  * 129  * This function should map an array of struct cifs_sids to an array of @@ -171,7 +171,7 @@ section is included below. 151  * 152  * This function should map an array of cifs_uxids an array of struct cifs_sids. 153  * Returns 0 if at least one conversion was successful and non-zero on error. - 154  * Any sids that were not successfully converted should have their revision + 154  * Any SIDs that were not successfully converted should have their revision 155  * number set to 0. 156  * 157  * On any error, the plugin should reset the errmsg pointer passed to the @@ -209,7 +209,7 @@ Testing with getcifsacl If there is no plugin for the CIFS client utilities or the plugin cannot resolve the SIDs to names getcifsacl will only show the SID strings in -the outout: :: +the output: :: # getcifsacl /tmp/bla/Users/Administrator/Desktop/putty.exe REVISION:0x1 @@ -261,17 +261,17 @@ calls using wbinfo: :: The following switches can be used to test the functions mentioned in the implementation section: :: - -n, --name-to-sid=NAME Converts name to sid - -s, --sid-to-name=SID Converts sid to name - -U, --uid-to-sid=UID Converts uid to sid - -G, --gid-to-sid=GID Converts gid to sid - -S, --sid-to-uid=SID Converts sid to uid - -Y, --sid-to-gid=SID Converts sid to gid + -n, --name-to-sid=NAME Converts name to SID + -s, --sid-to-name=SID Converts SID to name + -U, --uid-to-sid=UID Converts UID to SID + -G, --gid-to-sid=GID Converts GID to SID + -S, --sid-to-uid=SID Converts SID to UID + -Y, --sid-to-gid=SID Converts SID to GID -i, --user-info=USER Get user info - --uid-info=UID Get user info from uid + --uid-info=UID Get user info from UID --group-info=GROUP Get group info - --user-sidinfo=SID Get user info from sid - --gid-info=GID Get group info from gid + --user-sidinfo=SID Get user info from SID + --gid-info=GID Get group info from GID -r, --user-groups=USER Get user groups Additional links diff --git a/design_pages/ipa_server_mode.rst b/design_pages/ipa_server_mode.rst index 46453fc..5c0cff5 100644 --- a/design_pages/ipa_server_mode.rst +++ b/design_pages/ipa_server_mode.rst @@ -90,7 +90,7 @@ user, can be used). Now the AD provider code can be used to lookup up the users and group of the trusted AD domain. Only the ID-mapping logic should be refactored so that the same code can be used in the standalone AD provider where the -configuration is read form ssd.conf and as part of the IPA provider +configuration is read from sssd.conf and as part of the IPA provider where the idrange objects read from the IPA server dictates the mapping. Maybe libsss\_idmap can be extended to handle idranges for mappings in AD as well, e.g. a specific error code can be used to indicate to the @@ -186,7 +186,7 @@ idrange type or the mpg flag of the sss\_domain\_info struct and act accordingly. Additional the code paths where new subdomains are created must be -reviewed and whereever the mpg flag is set code must be added so that it +reviewed and wherever the mpg flag is set code must be added so that it is set according to the range type. Although I think that the code path where an IPA client (i.e. diff --git a/design_pages/kcm.rst b/design_pages/kcm.rst index 3e8b7ed..d14cc8a 100644 --- a/design_pages/kcm.rst +++ b/design_pages/kcm.rst @@ -98,7 +98,7 @@ domain must be enabled in order for SSSD to even generate the configuration. The identity of the ccache owner is read from the client socket connection. However, because in containerized environments, the same ID can often identify multiple apps, it is important to also track the SELinux label -as part of the client identity. This would prevent two continers running with +as part of the client identity. This would prevent two containers running with the same ID but different SELinux label to access each other's credentials. @@ -121,7 +121,7 @@ implemented, although this in-memory back end is not documented and should not be used in production. If the persistent storage in sssd-secrets (which is the default) is used, the KCM responder is allowed to idle-terminate. -For user credentialsm the KCM Server uses a secrets responder URI +For user credentials the KCM Server uses a secrets responder URI in the form of ``http://localhost/kcm/persistent/$uid`` where ``$uid`` is the user ID of the user whose credentials are being saved. In order to impersonate different users, the KCM responder runs as a trusted user @@ -129,7 +129,7 @@ impersonate different users, the KCM responder runs as a trusted user user can access the ``/kcm`` hive in the sssd-secrets responder. The peer identity consists of an UID/GID tuple that is read from the -client socket using ``getsockopt(SO_PEERCRED)`` and SELinux label.using +client socket using ``getsockopt(SO_PEERCRED)`` and SELinux label using ``SELINUX_getpeercon()``. To evaluate whether the MCS category the peer is running with can access the ccache potentially created with a different category, we'll call ``selinux_check_access()``. @@ -142,7 +142,7 @@ towards the KCM responder by a single UID are serialized. Internally in the secrets responder, the ccaches are stored at a new top-level anchor ``cn=kcm``. The secret responder's quotas on secrets also apply separately to the ``cn=kcm`` tree; separately here means -that is is allowed to store ``max_secrets`` secrets and at the same +that it is allowed to store ``max_secrets`` secrets and at the same time ``max_secrets`` credential caches. There is a `separate ticket `_ to make the quotas per-UID. @@ -161,7 +161,7 @@ secret's name) is a concatenation of the ccache's name and UUID. The value principal : { "type": "number", "realm": "string", - "componenents": [ "elem1", "elem2", ...] + "components": [ "elem1", "elem2", ...] } creds : [ @@ -219,7 +219,7 @@ must be enabled and started and the sssd-kcm service must be enabled:: # systemctl enable sssd-kcm.service Please note that starting the KCM socket auto-starts the sssd-secrets -socket so that the peristent secrets storage is available. +socket so that the persistent secrets storage is available. Then, set the ``KCM`` credential type as the default for the system. The ``sssd-kcm`` subpackage ships with a snippet file @@ -432,7 +432,7 @@ In this use-case, SSSD is running in one container and keeps track of ccaches in other containers that are completely separated from the host environment. The containers must also share the credential caches between one another. -#. Start a container that will run an SSSD instace with the KCM service. We +#. Start a container that will run an SSSD instance with the KCM service. We name the container ``kcmserver`` and assign a volume called ``/kcmserver`` to this container:: @@ -512,7 +512,7 @@ The containers must also share the credential caches between one another. #. Start another container as another KCM client, configure its ``krb5.conf`` configuration file in the same manner. As long as this container runs as the same UID as the first KCM client, the credentials should be visible - in this container immediatelly without having to acquire them:: + in this container immediately without having to acquire them:: kcmclient2 # klist Ticket cache: KCM:0 diff --git a/design_pages/ldap_referrals.rst b/design_pages/ldap_referrals.rst index 1328c6f..99b83d5 100644 --- a/design_pages/ldap_referrals.rst +++ b/design_pages/ldap_referrals.rst @@ -92,7 +92,7 @@ Questions needing research This is potentially chaotic, as it introduces multiple points of failure resulting in offline operation. #. Flag unreachable entries as "complete", thereby having SSSD rely - on their presence or abscence in the cache. While this sounds nice + on their presence or absence in the cache. While this sounds nice in theory, I think this would probably be very difficult to get right, especially with enumeration. I recommend deferring this as a future optimization and going with one of the other approaches diff --git a/design_pages/local_group_members_for_rfc2307.rst b/design_pages/local_group_members_for_rfc2307.rst index f5627b0..d39c704 100644 --- a/design_pages/local_group_members_for_rfc2307.rst +++ b/design_pages/local_group_members_for_rfc2307.rst @@ -56,7 +56,7 @@ returned. The groups returned are the ones found in LDAP that have this user's name in the memberUid attribute. SSSD backends disable by default recursion from nsswitch calls into SSSD -itslef. It is therefore safe to call functions like getpwnam() or +itself. It is therefore safe to call functions like getpwnam() or getpwuid() from within a backend. These functions will not enter the nss client and will return all users from any other backend listed in nsswitch.conf for the 'passwd' database. diff --git a/design_pages/lookup_users_by_certificate.rst b/design_pages/lookup_users_by_certificate.rst index b8d3555..0099d71 100644 --- a/design_pages/lookup_users_by_certificate.rst +++ b/design_pages/lookup_users_by_certificate.rst @@ -72,9 +72,9 @@ added here or not?) To search a user with the help of the certificate the DER encoded binary ticket must be transformed into a search filter. In this case it would be something like 'userCertificate=\\23\\a5\\3e......' where each byte -from the certificate is is represented by a hex value pre-pendened by a +from the certificate is represented by a hex value prepended by a '\\'. The filter should be generated in a subroutine which accepts the -DER encoded certificate with base64 ascii armor and returns the search +DER encoded certificate with base64 ASCII armor and returns the search filter. This way the subroutine can later be extended to accept configuration options for the identity mapping and can return different search filters for those cases. Since the requirement for LDAP and sysdb @@ -83,7 +83,7 @@ LDAP or sysdb filter is needed, because the attribute names might be different. Although it would be possible to handle the binary DER data directly I -think using a base64 ascii armor to handle the data as a string is +think using a base64 ASCII armor to handle the data as a string is useful to avoid adding code for handling binaries e.g. in the S-BUS requests to the backends. @@ -91,7 +91,7 @@ SYSDB API ^^^^^^^^^ A new call sysdb\_search\_user\_by\_cert() should be added which get the -DER encoded certificate with base64 ascii armor as input and use the +DER encoded certificate with base64 ASCII armor as input and use the function described above to get a proper search filter. Currently it will be only the search filter for the binary certificate. Other than that the new call will act like to other sysdb\_search\_user\_by\_\*() @@ -101,11 +101,11 @@ InfoPipe ^^^^^^^^ A new method GetUSerAttrByCert() must be implemented which expected the -PEM encoded certificate and an array of attrbute names. **Question: +PEM encoded certificate and an array of attribute names. **Question: Should we only support PEM here or other formats as well? In this case we need a third parameter indicating the encoding of the certificate data.**. -InfoPipe will convert the certificate into DER encoding with base64 ascii +InfoPipe will convert the certificate into DER encoding with base64 ASCII armor, search the cache and eventually forward the request to the backend. The request to the backend is processed similar to a request by name, only that a new filter name, e.g. DP\_CERT\_ID "cert", is needed. diff --git a/design_pages/lookup_users_by_certificate_part2.rst b/design_pages/lookup_users_by_certificate_part2.rst index c237830..85a2486 100644 --- a/design_pages/lookup_users_by_certificate_part2.rst +++ b/design_pages/lookup_users_by_certificate_part2.rst @@ -90,7 +90,7 @@ Configuration changes ~~~~~~~~~~~~~~~~~~~~~ For the AD provider the currently unset option *ldap\_user\_certificate* -will be set to *userCertificate;binary*. This means that is a +will be set to *userCertificate;binary*. This means that if a certificate is available in the user entry it will be downloaded and written to the cache by default. To avoid this *ldap\_user\_certificate* must be set to a non-existing attribute name like e.g. :: @@ -98,7 +98,7 @@ must be set to a non-existing attribute name like e.g. :: ldap_user_certificate = nonExistingAttributeName The *sss\_override user-add* utility has a new option *--certificate* -(*-x*) which expects the base64-endode certificate as an argument. +(*-x*) which expects the base64-encoded certificate as an argument. How To Test ~~~~~~~~~~~ diff --git a/design_pages/matching_and_mapping_certificates.rst b/design_pages/matching_and_mapping_certificates.rst index 2854eef..a8701ae 100644 --- a/design_pages/matching_and_mapping_certificates.rst +++ b/design_pages/matching_and_mapping_certificates.rst @@ -54,7 +54,7 @@ from the certificate item can be used in a LDAP search filter. Implementation details ^^^^^^^^^^^^^^^^^^^^^^ -Since certificates form different CAs (i.e. a different issuer) might have +Since certificates from different CAs (i.e. a different issuer) might have different properties and might be used in different domains mapping rules cannot be applied unconditionally but only to "matching" certificates. On the other hand it is not sufficient to know that a certificate is @@ -538,7 +538,7 @@ search filter will combine both with the or-operator. The optional ``*`` in the end indicates that a sub-string search (``ldapAttributeName=*value*``) should be used and not an exact match (``ldapAttributeName=value``). Please note that it depends on the server-side -definition of the LDAP attribute if case-sensitive or case-insensitve +definition of the LDAP attribute if case-sensitive or case-insensitive matching is used. Currently I see no usage for ```` and ```` in mapping rules @@ -569,7 +569,7 @@ because AFAIK there is not library which offers this and I would like to avoid implementing it. GLib e.g. has `g_regex_replace `_ Since we already have a GLib dependency in SSSD due to -soem utf8 helper functions using might be acceptable as well. Nevertheless it +some UTF-8 helper functions using might be acceptable as well. Nevertheless it would be nice to hear if there are alternative libraries available as well. Maybe even search-and-replace are not sufficient for all cases and something @@ -646,7 +646,7 @@ Examples mapping_rule = certificate_domains = my-company.com - only allow certificates form the 'my-company' issuer which + only allow certificates from the 'my-company' issuer which have an email address from the 'my-company.com' domain in the rfc882Name SAN attribute. Use AD style issuer-subject search filter ``(altSecurityIdentities=cn=issuer,dc=my-company,dc=comcn=user,dc=my-company,dc=com)`` diff --git a/design_pages/netgroups.rst b/design_pages/netgroups.rst index bbdd56c..9cfc605 100644 --- a/design_pages/netgroups.rst +++ b/design_pages/netgroups.rst @@ -96,7 +96,7 @@ Lower-level - setnetgrent ^^^^^^^^^^^^^^^^^^^^^^^^^ #. Incoming requests to the SSSD will behave similarly to the user and - group enumaration code, except that the individual result objects for + group enumeration code, except that the individual result objects for different netgroup names will be stored in a hash table keyed on the netgroup name. #. During processing, if a netgroup contains nested netgroups, we will diff --git a/design_pages/non_posix_support.rst b/design_pages/non_posix_support.rst index 7825f7a..305603b 100644 --- a/design_pages/non_posix_support.rst +++ b/design_pages/non_posix_support.rst @@ -76,7 +76,7 @@ Internally, this would create an SSSD domain as well, just marked as a non-POSIX one. An application domain section can be either defined as a standalone -domain, listing all the needed options or can be used in conjuction with +domain, listing all the needed options or can be used in conjunction with a traditional POSIX domain in mixed setups. In this case, the application domain can use the ``inherit_from`` option to inherit all options from the "sibling" POSIX domain. Any options specified in the application domain @@ -107,7 +107,7 @@ in the sense that the OS-level PAM interface will be usable even without qualified names. For distinguishing accounts between a POSIX and an application domain from -the D-Bus inteface, a fully qualified name must be used. But since the +the D-Bus interface, a fully qualified name must be used. But since the D-Bus interface is normally used only by the application, putting the application domain first in the ``domains`` list should be enough to avoid using qualified names from the application while still making it possible @@ -284,7 +284,7 @@ mix of POSIX and non-POSIX groups in the mixed scenario setups. ``appdomain.test`` domain completely. * Since the ``appdomain.test`` domain comes first in the domain - list, running ``GetUserAttr`` with an unqalified name should + list, running ``GetUserAttr`` with an unqualified name should return non-POSIX users * Also invoking the ``GetUserGroups`` function should list their non-POSIX groups. Requests qualified to reach the @@ -306,7 +306,7 @@ How To Debug ------------ Debug messages listing the domain type must be added to the ``cache_req`` code. Then, the regular method of issuing a request and watching the logs -should work. Expiring the cache and using the qualified names is recommeded. +should work. Expiring the cache and using the qualified names is recommended. Authors ------- diff --git a/design_pages/not_root_sssd.rst b/design_pages/not_root_sssd.rst index 42e43b5..7e83ea6 100644 --- a/design_pages/not_root_sssd.rst +++ b/design_pages/not_root_sssd.rst @@ -486,7 +486,7 @@ Splitting the back end initialization into privileged and unprivileged part It was proposed on the sssd-devel list that the initialization of the sssd\_be process is split into a privileged and non-privileged function. The back end would open all providers, call the privileged -initialization functions and then drop privileges. Currenly all +initialization functions and then drop privileges. Currently all initialization is done as root, which is not strictly required in many setups. @@ -514,7 +514,7 @@ handling capabilities ourselves with prctl The downside is obviously the extra dependency, but libcap-ng has a small footprint and is already used by packages that are present on -most, if not all, modern Linux installations, such as dbus. +most, if not all, modern GNU/Linux installations, such as dbus. We would keep the existing code around as a fallback for environments that don't have the libcap-ngs library available, such as non-Linux diff --git a/design_pages/nss_responder_id_mapping_calls.rst b/design_pages/nss_responder_id_mapping_calls.rst index 59c426b..d4f0645 100644 --- a/design_pages/nss_responder_id_mapping_calls.rst +++ b/design_pages/nss_responder_id_mapping_calls.rst @@ -177,7 +177,7 @@ memory allocators (e.g. talloc). I think it is not necessary to add special set of return values/error code but the standard ones are sufficient. Maybe ENETUNREACH it indicate that SSSD could not find the right domain for the request could be -replaced by a better one. (EDOM would be a candidate, but imo it should +replaced by a better one. (EDOM would be a candidate, but IMO it should be reserved for mathematical operations.) Python bindings @@ -197,10 +197,10 @@ make testing easier and might help user and administrators as well. # sss_idmap --help Usage: sss_idmap [OPTION...] - -n, --name-to-sid=NAME Converts name to sid - -s, --sid-to-name=SID Converts sid to name - -S, --sid-to-id=SID Converts sid to POSIX ID - -i, --id-to-sid=ID Converts POSIX ID to sid + -n, --name-to-sid=NAME Converts name to SID + -s, --sid-to-name=SID Converts SID to name + -S, --sid-to-id=SID Converts SID to POSIX ID + -i, --id-to-sid=ID Converts POSIX ID to SID Help options: -?, --help Show this help message diff --git a/design_pages/nss_with_kerberos_principal.rst b/design_pages/nss_with_kerberos_principal.rst index 2caf2ab..d723a62 100644 --- a/design_pages/nss_with_kerberos_principal.rst +++ b/design_pages/nss_with_kerberos_principal.rst @@ -15,10 +15,10 @@ Problem Statement ----------------- When using Kerberos/GSSAPI authentication for a service running on a -Linux host strictly speaking not a POSIX user of the Linux system is +GNU/Linux host strictly speaking not a POSIX user of the GNU/Linux system is authenticated but a Kerberos principal. I.e. authentication is successful for every Kerberos principal with a valid ticket for the -service running on the Linux host. This is done intentional to keep +service running on the GNU/Linux host. This is done intentional to keep Kerberos independent of the operating system of the host. But it creates the problem of mapping Kerberos principals to POSIX users. @@ -26,7 +26,7 @@ Basic mappings are integrated in the MIT Kerberos library. By default the realm part of the Kerberos principal is stripped off and what remains is considered as a POSIX user name. The administrator can enhance this by adding some minimal regular-expression operations in -/etc/krb5.conf. Addionally the user can create a .k5login file in his +/etc/krb5.conf. Additionally the user can create a .k5login file in his home directory and add all Kerberos principals which should be allowed to log in with his identity. All those methods do not scale in environments with multiple realm and cross-realm trust. @@ -79,7 +79,7 @@ One way to solve this is to introduce a special prefix tag, e.g. considered as a Kerberos principal and not be split as fully qualified user names. While this would work for the localauth plugin use-case there are other potential use-cases where this would not be possible. -E.g if SSSD should allow AD user to use their UPN (see +E.g. if SSSD should allow AD user to use their UPN (see `http://technet.microsoft.com/en-us/library/cc739093(v=WS.10).aspx `__ for details). This UPN is build by joining the user logon name and a UPN suffix with an '@' character. I think it cannot be expected from the AD @@ -88,7 +88,7 @@ because it does not know it is a fully qualified name or a UPN. Especially with the second use-case, we should process the argument of getpwnam() like a fully qualified user name first. If no matching user -was found during this pass SSSD can take the orginal input, check if it +was found during this pass SSSD can take the original input, check if it contains an '@' character and search the configured backends for a matching Kerberos principal or UPN. It has to be noted that in theory there might be a user with the fully qualified name ``abc@domain.name`` @@ -172,7 +172,7 @@ searched with the fully qualified name. ``getent passwd testabc@MY.REALM`` will return the same entry but now search with the Kerberos principal. -Additionaly, logging in as a Windows user using GSSAPI should succeed +Additionally, logging in as a Windows user using GSSAPI should succeed without requiring password with stock krb5.conf on an IPA client when IPA-AD trust is established, as the following sequence illustrates: :: diff --git a/design_pages/one_fifteen_code_refactoring.rst b/design_pages/one_fifteen_code_refactoring.rst index da1b2b5..2529e22 100644 --- a/design_pages/one_fifteen_code_refactoring.rst +++ b/design_pages/one_fifteen_code_refactoring.rst @@ -363,7 +363,7 @@ Failover refactoring Failover mechanism wasn't prepared for subdomains and we run into troubles every now and then. We added several workarounds for cases where the original code wasn't sufficient but it made the code just more -confused. At this moment nobody understands it but bugs keeps comming. +confused. At this moment nobody understands it but bugs keeps coming. We should have a separate failover context for each domain, instead of one per whole backend. It must be possible to set different srv @@ -373,7 +373,7 @@ between contexts. Benefit to SSSD ^^^^^^^^^^^^^^^ -We remove old and problematic code that knowbody understands. We can +We remove old and problematic code that nobody understands. We can improve site discovery for trusted domains and we can have better control over subdomain server resolution. diff --git a/design_pages/one_fourteen_performance_improvements.rst b/design_pages/one_fourteen_performance_improvements.rst index 681335c..c5a1e3e 100644 --- a/design_pages/one_fourteen_performance_improvements.rst +++ b/design_pages/one_fourteen_performance_improvements.rst @@ -22,11 +22,11 @@ Use cases ~~~~~~~~~ - User who is a member of a large amount of AD groups logs in to a - Linux server that is a member of the AD domain. + GNU/Linux server that is a member of the AD domain. - User who is a member of a large amount of AD or IPA groups logs in to - a Linux server that is a member of an IPA domain with a trust + a GNU/Linux server that is a member of an IPA domain with a trust relationship to an AD domain -- Administrator of a Linux server runs "ls -l" in a directory where +- Administrator of a GNU/Linux server runs "ls -l" in a directory where files are owned by a large group. An example would be group called "students" in an university setup diff --git a/design_pages/one_way_trusts.rst b/design_pages/one_way_trusts.rst index 4c4385d..4cece19 100644 --- a/design_pages/one_way_trusts.rst +++ b/design_pages/one_way_trusts.rst @@ -26,7 +26,7 @@ At a high level, SSSD needs to examine the trust objects whether they are one-way or two way trusts. For each one-way trust, SSSD needs to fetch and store the keytab and use the keytab to secure the connection. For two-way trusts, we can keep using the existing code that reuses the -IPA realm and the system keytab for both IPA and AD connectins. Care +IPA realm and the system keytab for both IPA and AD connections. Care must be taken to remove keytabs of trusts that were removed as well. Fetching the keytab would be done by calling the ``ipa-getkeytab`` @@ -73,7 +73,7 @@ is no keytab, the subdomain handler will fork out a call to ``ipa-getkeytab``, fetch the keytab and store it under ``/var/lib/sss/keytabs``. The ``ipa-getkeytab`` call will be done using Kerberos credentials the host has. IPA ACIs must be modified accordingly -to allow the IPA server principals to fetch the trust keytabs, but noone +to allow the IPA server principals to fetch the trust keytabs, but nobody else. The SSSD invocation of ``ipa-getkeytab`` will not limit the enctypes in any way, we just rely on IPA creating the objects in LDAP in the correct manner. @@ -169,7 +169,7 @@ offline code. In both offline and inactive cases, the ID handlers would reply with ``DP_ERR_OFFLINE``. The crucial difference between offline and inactive at this point would be that inactive domains are re-activated -undonditionally. When we modify the failover code to handle domains +unconditionally. When we modify the failover code to handle domains separately, we'll be able to leverage per-domain online checks or online/offline callbacks as well. diff --git a/design_pages/open_lmi_provider.rst b/design_pages/open_lmi_provider.rst index a574678..28ca00a 100644 --- a/design_pages/open_lmi_provider.rst +++ b/design_pages/open_lmi_provider.rst @@ -5,7 +5,7 @@ Problem Statement ----------------- SSSD provider for OpenLMI will allow administrators to retrieve -information from SSSD and modify the configuration through OpemLMI +information from SSSD and modify the configuration through OpenLMI tools. First iteration diff --git a/design_pages/pam_conversation_for_otp.rst b/design_pages/pam_conversation_for_otp.rst index 59fa0fd..60898c1 100644 --- a/design_pages/pam_conversation_for_otp.rst +++ b/design_pages/pam_conversation_for_otp.rst @@ -106,7 +106,7 @@ can handle only a single password prompt. To keep the delays due to the new request to a minimum pam\_sss should only run it, if the backend really supports it. Additionally is should -be possilbe to disable the pre-authentication request completely with a +be possible to disable the pre-authentication request completely with a new option for pam\_sss. In addition to the authentication dialog the password change dialog diff --git a/design_pages/prompting_for_multiple_authentication_types.rst b/design_pages/prompting_for_multiple_authentication_types.rst index 9a00e9c..8792232 100644 --- a/design_pages/prompting_for_multiple_authentication_types.rst +++ b/design_pages/prompting_for_multiple_authentication_types.rst @@ -144,7 +144,7 @@ for details. Additionally two services with different authentication indicator requirements are useful to test the returned credentials but are not necessary to test the prompting. :: - $ ipa service-add ANY/ipa-client.example.dom + $ ipa service-add ANY/ipa-client.example.com $ ipa-getkeytab -p ANY/ipa-client.example.com -k /tmp/any.keytab $ ipa service-add OTP/ipa-client.example.com --auth-ind=otp @@ -166,10 +166,10 @@ and then as an un-privileged user :: after login you can test by calling :: - $ kvno ANY/ipa-client.example.dom@EXAMLE.COM + $ kvno ANY/ipa-client.example.com@EXAMPLE.COM ANY/ipa-client.example.com@EXAMPLE.COM: kvno = 1 - $ kvno OTP/ipa-client.example.dom@EXAMLE.COM - kvno: KDC policy rejects request while getting credentials for OTP/ipa-client.example.dom@EXAMLE.COM + $ kvno OTP/ipa-client.example.com@EXAMPLE.COM + kvno: KDC policy rejects request while getting credentials for OTP/ipa-client.example.com@EXAMPLE.COM that only a ticket for the ANY service can be requested but not for the OTP service because only the password was used for authentication. @@ -191,9 +191,9 @@ and then as an un-privileged user call :: after login you can test by calling :: - $ kvno ANY/ipa-client.example.dom@EXAMLE.COM + $ kvno ANY/ipa-client.example.com@EXAMPLE.COM ANY/ipa-client.example.com@EXAMPLE.COM: kvno = 1 - $ kvno OTP/ipa-client.example.dom@EXAMLE.COM + $ kvno OTP/ipa-client.example.com@EXAMPLE.COM OTP/ipa-client.example.com@EXAMPLE.COM: kvno = 1 that tickets for both services can be request successfully because now @@ -201,7 +201,7 @@ that tickets for both services can be request successfully because now Entering Password+TokenValue in a single string at the *First Factor:* prompt will authenticate the user successfully as well but features like off-line authentication or unlocking of the user's keyring might -not be availble. +not be available. Password and OTP '''''''''''''''' @@ -221,17 +221,17 @@ prompt or enter the password and the OTP token value at the respective prompt. In the first case only a ticket for the ANY service can be requested: :: - $ kvno ANY/ipa-client.example.dom@EXAMLE.COM + $ kvno ANY/ipa-client.example.com@EXAMPLE.COM ANY/ipa-client.example.com@EXAMPLE.COML: kvno = 1 - $ kvno OTP/ipa-client.example.dom@EXAMLE.COM - kvno: KDC policy rejects request while getting credentials for OTP/ipa-client.example.dom@EXAMLE.COM + $ kvno OTP/ipa-client.example.com@EXAMPLE.COM + kvno: KDC policy rejects request while getting credentials for OTP/ipa-client.example.com@EXAMPLE.COM If both factor are given tickets for both services can be requested successfully: :: - $ kvno ANY/ipa-client.example.dom@EXAMLE.COM + $ kvno ANY/ipa-client.example.com@EXAMPLE.COM ANY/ipa-client.example.com@EXAMPLE.COM: kvno = 1 - $ kvno OTP/ipa-client.example.dom@EXAMLE.COM + $ kvno OTP/ipa-client.example.com@EXAMPLE.COM OTP/ipa-client.example.com@EXAMPLE.COM: kvno = 1 Entering Password+TokenValue in a single string at the @@ -244,7 +244,7 @@ How To Debug If password authentication is not working when both password and OTP authentication are enabled you might hit `https://bugzilla.redhat.com//show\_bug.cgi?id=1340304 `__ -and should update the Kerbeors packages. +and should update the Kerberos packages. Inspecting log files ^^^^^^^^^^^^^^^^^^^^ diff --git a/design_pages/restrict_domains_in_pam.rst b/design_pages/restrict_domains_in_pam.rst index 68eba6d..aae52d6 100644 --- a/design_pages/restrict_domains_in_pam.rst +++ b/design_pages/restrict_domains_in_pam.rst @@ -113,7 +113,7 @@ Password Changes Password changes should be allowed against all domains, meaning that a user A (recognized via getpeercred) will be allow to perform a password -change, ie implicitly allowed to access its own domain even if it is +change, i.e. implicitly allowed to access its own domain even if it is untrusted. Arbitrary password changes for other users should not be allowed. @@ -137,7 +137,7 @@ How To Test #. Authenticate using the selected PAM service as a user from domain A. The authentication should succeed. #. Authenticate using the same service as a user from domain B. The - authentication should fail and there should be a reasonable (ie not + authentication should fail and there should be a reasonable (i.e. not System Error) return code returned to the application #. Authenticate using a different PAM service. Make sure this service is ran by an untrusted user (not root!). Logins against both A and B diff --git a/design_pages/rpc_idmapd_plugin.rst b/design_pages/rpc_idmapd_plugin.rst index f2b4b79..3ad3456 100644 --- a/design_pages/rpc_idmapd_plugin.rst +++ b/design_pages/rpc_idmapd_plugin.rst @@ -1,7 +1,7 @@ SSS NFS Client (rpc.idmapd plugin) ================================== -The client is named "**sss\_nfs**" (althogh "sss\_idmap" or "idmap" +The client is named "**sss\_nfs**" (although "sss\_idmap" or "idmap" might have been better names, the term "idmap" is already occupied in the SSSD world). @@ -12,11 +12,11 @@ rpc.idmapd runs on NFSv4 servers as a userspace daemon (part of nfs-utils). Its role is to assist knfsd by providing the following 6 mapping functions: -#. (user) name to uid -#. (group) name to gid -#. uid to (user) name -#. gid to (group) name -#. principal (user) name to ids (uid + gid) +#. (user) name to UID +#. (group) name to GID +#. UID to (user) name +#. GID to (group) name +#. principal (user) name to ids (UID + GID) #. principal (user) name to grouplist (groups which user are member of) .. FIXME: The last two items had the following note below them @@ -29,7 +29,7 @@ which implements the actual mapping process. On the kernel level, there's a caching mechanism for the responses from the userspace daemon. -\ :sup:`(1)` Items 5 + 6 are only relevant for kerberised NFSv4 servers. +\ :sup:`(1)` Items 5 + 6 are only relevant for kerberized NFSv4 servers. At the first stage only there won't be kerberos support. SSSD - Responder @@ -46,16 +46,16 @@ SSSD - NFS Client Responder-Facing Interactions (existing NSS Responder commands) -- ``SSS_NSS_GETPWNAM`` - map (user) name to uid requests -- ``SSS_NSS_GETGRNAM`` - map (group) name to gid requests -- ``SSS_NSS_GETPWUID`` - map uid to (user) name requests -- ``SSS_NSS_GETGRGID`` - map gid to (group) name requests +- ``SSS_NSS_GETPWNAM`` - map (user) name to UID requests +- ``SSS_NSS_GETGRNAM`` - map (group) name to GID requests +- ``SSS_NSS_GETPWUID`` - map UID to (user) name requests +- ``SSS_NSS_GETGRGID`` - map GID to (group) name requests The request & reply sent to & from the responder is "standard" in terms of the NSS Responder. The client only needs a portion of the reply. Only this portion will be -extracted from the packet (i.e. uid/gid/user name/group name). +extracted from the packet (i.e. UID/GID/user name/group name). Optimisation Techniques ~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/design_pages/secrets_service.rst b/design_pages/secrets_service.rst index 4ce7aee..e0abc4f 100644 --- a/design_pages/secrets_service.rst +++ b/design_pages/secrets_service.rst @@ -19,7 +19,7 @@ to deal with this problem in cloud like environments, but we found the idea compelling even at a single system level. As a security service sssd is ideal to host this capability while offering the same `API `__ via a -Unix Socket. This will make it possible to use local calls and have them +UNIX Socket. This will make it possible to use local calls and have them transparently routed to a local or a remote key management store like `IPA Vault `__ or `HashiCorp's Vault `__ for storage, escrow @@ -41,7 +41,7 @@ Overview of the solution ~~~~~~~~~~~~~~~~~~~~~~~~ This feature will be implemented by creating a new responder process -that handles the REST API over a Unix Socket, and will route requestes +that handles the REST API over a UNIX Socket, and will route requests either to a local database separate from the generic ldb caches or to a provider that can implement remote backends like IPA Vault to store some or all the secrets of a user or a system application. @@ -122,7 +122,7 @@ The API should be as follow: :: void secrets_list_contents_free(struct secrets_list *list); void secrets_data_contents_free(struct secrets_data *data); -The API uses eclusively the "simple" secret type. +The API uses exclusively the "simple" secret type. Resource Considerations ^^^^^^^^^^^^^^^^^^^^^^^ diff --git a/design_pages/shortnames.rst b/design_pages/shortnames.rst index 662a385..937609a 100644 --- a/design_pages/shortnames.rst +++ b/design_pages/shortnames.rst @@ -22,7 +22,7 @@ forest to configure its IdM servers and associated IdM clients to allow user domains) to be possible by using only the short names without the domain component, as it's done by some 3rd party solutions. It's important to mention that the Administrator has also the possibility to -configure it for directly AD joined clients, althought it cannot be done in a +configure it for directly AD joined clients, although it cannot be done in a centralized way (meaning that the configuration has to be done per SSSD client). @@ -37,7 +37,7 @@ Once domain-less searches are allowed, SSSD will have to support receiving an ordered list of domains which will be looked-up first so the Administrator can have a better control and avoid a bunch of unnecessary look-ups. The list of the ordered domains can be provided in three different ways and those are -described below accoding to their precedence order: +described below according to their precedence order: * sssd.conf: the admin can set up the ``domain_resolution_order`` option in the ``[sssd]`` section; diff --git a/design_pages/smartcard_authentication_pkinit.rst b/design_pages/smartcard_authentication_pkinit.rst index 8831e6b..96b78b6 100644 --- a/design_pages/smartcard_authentication_pkinit.rst +++ b/design_pages/smartcard_authentication_pkinit.rst @@ -100,8 +100,8 @@ specifies the location of a library implementing PKCS\ `#11 `__. If a value is encountered with no keyword, it is assumed to be the modname. If no module-name is specified, the default is opensc-pkcs11.so. slotid= -and/or token= may be specified to force the use of a particular smard -card reader or token if there is more than one available. certid= and/or +and/or token= may be specified to force the use of a particular smartcard +reader or token if there is more than one available. certid= and/or certlabel= may be specified to force the selection of a particular certificate on the device. See the pkinit\_cert\_match configuration option for more ways to select a particular certificate to use for @@ -154,14 +154,14 @@ need to be set on the client to make PKINIT work, By default the PKINIT plugin of MIT Kerberos expects that the KDC certificate contains the id-pkinit-KPKdc EKU as defined in RFC 4556 and -has the kdc's hostname in id-pkinit-san as defined in RFC4556 as well. +has the KDC's hostname in id-pkinit-san as defined in RFC4556 as well. If id-pkinit-san is missing 'pkinit\_kdc\_hostname' can be set to the -hostname of the kdc as stored in the dNSName in the SAN of the +hostname of the KDC as stored in the dNSName in the SAN of the certificate. If the dNSName SAN is missing as well, PKINIT won't work. If the id-pkinit-KPKdc EKU is not set 'pkinit\_eku\_checking' can be set -to 'kpServerAuth' is the certificate of the kdc at least contains the +to 'kpServerAuth' is the certificate of the KDC at least contains the id-kp-serverAuth EKU. If this is missing as well 'pkinit\_eku\_checking' can be set to 'none', but this is not recommended. diff --git a/design_pages/smartcard_authentication_step1.rst b/design_pages/smartcard_authentication_step1.rst index 8c099c1..05eff90 100644 --- a/design_pages/smartcard_authentication_step1.rst +++ b/design_pages/smartcard_authentication_step1.rst @@ -114,7 +114,7 @@ entry e.g. the console login prompt should now ask for a PIN instead of a password and if the correct PIN is entered the user should be successfully authenticated and logged in. -Runnning a ssh client with Smartcard support +Running an ssh client with Smartcard support '''''''''''''''''''''''''''''''''''''''''''' The *ssh* client program distributed with Fedora or RHEL contains @@ -167,7 +167,7 @@ Running ssh client with Smartcard support The PKCS#11 module for accessing certificates and private keys in a NSS database is *libsoftokn3.so*. But unfortunately this modules needs some -configuration option when loaded and there is (afaik) currently no way +configuration option when loaded and there is (AFAIK) currently no way to pass them with the *ssh* command. Luckily there is p11-kit which can be used to load *libsoftokn3.so* with options. In the following we assume that the certificate and the private key is stored in an NSS DB diff --git a/design_pages/smartcard_authentication_testing_with_ad.rst b/design_pages/smartcard_authentication_testing_with_ad.rst index cf35ada..771a8a0 100644 --- a/design_pages/smartcard_authentication_testing_with_ad.rst +++ b/design_pages/smartcard_authentication_testing_with_ad.rst @@ -72,20 +72,20 @@ as well. Now you have to write the certificate and the keys to a Smartcard. You can use a suitable Windows tool for this. Or you can export the data and -write it to a Smartcard from a Linux client which will be explained in +write it to a Smartcard from a GNU/Linux client which will be explained in the following. To export the certificate select it in the Certificates Snap-in and call 'Export' from the 'All Tasks' context menu. In the export wizard the private key must be exported as well. The generated file can now be -copied to a Linux host. +copied to a GNU/Linux host. The file created on the AD side is PKCS#12 formatted and can be inspected -on the Linux side with the *openssl pkcs12* utility. NSS, which is +on the GNU/Linux side with the *openssl pkcs12* utility. NSS, which is currently used by SSSD to access the Smartcard, expected that the Smartcard will contain the certificate together with the public and private key in separate objects, connected by the same label and id. -We will use pkcs11-tool form the opensc package to write the data to the +We will use pkcs11-tool from the opensc package to write the data to the card. In general p11tool from the gnutls project can be used as well but support for writing public keys was added quite recently (gnutls-3.4.6) so it might no be available on your platform. There might be an issue @@ -116,11 +116,11 @@ encoding :: Writing certificate and keys to a Smartcard ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -First write the certificate data to the Samrtcard by calling :: +First write the certificate data to the Smartcard by calling :: pkcs11-tool --module my_pkcs11_module.so --slot 0 -w ./cert.der -y cert -a 'My Label' --id 0123456789abcdef0123456789abcdef01234567 -where *my\_pkcs11\_module.so* and *My Label* shou be replaced by +where *my\_pkcs11\_module.so* and *My Label* should be replaced by suitable values. The id value is typically the Subject Key Identifier which is typically the sha1 hash value of the public key bit string from the certificate. The value can either obtained from the output of :: @@ -186,10 +186,10 @@ with the help of the Smartcard. Certificate from an external CA ------------------------------- -There are various way how to get a certificate from an extrernal CA, see +There are various ways how to get a certificate from an external CA, see e.g. `https://blog-nkinder.rhcloud.com/?p=179 `__ -how to generate the keys on a Smartcard, request a certificate form a CA +how to generate the keys on a Smartcard, request a certificate from a CA and store it on the Smartcard. As a result the certificate and all the needed keys are already on the Smartcard. In the following we will explain how to make AD aware of it and enable local Smartcard login for diff --git a/design_pages/smartcards_and_multiple_identities.rst b/design_pages/smartcards_and_multiple_identities.rst index 892ec6c..a04fc59 100644 --- a/design_pages/smartcards_and_multiple_identities.rst +++ b/design_pages/smartcards_and_multiple_identities.rst @@ -78,7 +78,7 @@ use case where one certificate is used to log in to different accounts (which of course are identified by different user names). For the forth case a new PAM dialog/conversation is needed. -To my knowlegde there are currently two cases where a user name is not +To my knowledge there are currently two cases where a user name is not available in the first place, InfoPipe lookups by certificate used e.g. by `mod\_lookup\_identity `__ and the GDM Smartcard module which calls pam\_start() with an empty user @@ -104,7 +104,7 @@ code that either none or multiple users match the certificate. In the latter case the application can ask for a user name. For the gdm case it might be useful to see how Smartcard authentication -is handled on Windows. To illustrate this I prepare two short screencast +is handled on Windows. To illustrate this I prepare two short screencasts (sorry for the raw state, if time permits I will improve them). `The @@ -147,7 +147,7 @@ messages and prompts at the same time as Windows does to make it more clear to the user what input is expected and why. If it is needed to select a certificate the typical PAM service will -display specific data from the certificates, e.g. the valie of the most +display specific data from the certificates, e.g. the value of the most specific RDN of the subject and the full DN of the issuer, in a numbered list asking the user to enter the number of the certificate which should be used for login. If would be nice if gdm can display this list in a @@ -155,7 +155,7 @@ more graphical way and make it possible to select the certificate with a mouse-click. Since SSSD knows that it is called by gdm because of the PAM service name, e.g. gdm-smartcard, it would be possible to send the certificate data with a new messages style, e.g. -PAM\_SELECTON\_LIST\_ITEM like the Linux specific PAM\_RADIO\_TYPE. Then +PAM\_SELECTON\_LIST\_ITEM like the GNU/Linux specific PAM\_RADIO\_TYPE. Then gdm would be able to display the certificate selection in a more suitable way, e.g. similar to the selection of user names. diff --git a/design_pages/socket_activatable_responders.rst b/design_pages/socket_activatable_responders.rst index 45e1086..4cd4389 100644 --- a/design_pages/socket_activatable_responders.rst +++ b/design_pages/socket_activatable_responders.rst @@ -67,7 +67,7 @@ changes in the monitor code in order to manage the new activated service. The change in the responders' common code is quite trivial, just change -the sss\_process\_init code to call activate\_unix\_sockets() istead of +the sss\_process\_init code to call activate\_unix\_sockets() instead of set\_unix\_socket(). Something like: :: - ret = set_unix_socket(rctx, conn_setup); diff --git a/design_pages/sssctl.rst b/design_pages/sssctl.rst index 59838d1..a583af1 100644 --- a/design_pages/sssctl.rst +++ b/design_pages/sssctl.rst @@ -71,7 +71,7 @@ We can also get more information about specific domain. :: # sssctl domain-status $domain [--online, --last-request, --active-server, --servers] Online status: Online/Offline - Active server: $currently-conected-server (server status, port status, resolver status) + Active server: $currently-connected-server (server status, port status, resolver status) Primary servers: first.example.com (server status, port status, resolver status) @@ -186,23 +186,23 @@ Questions ~~~~~~~~~ - **Q1**: [Domain; Last request] What would be preferred number of - request to be printed? Do we wan't a parameter for this in sssd.conf + request to be printed? Do we want a parameter for this in sssd.conf or even make it possible to change this value dynamically? - Start with fixed number of 10 request and keep it unless a bigger - requirenment comes. + requirement comes. - **Q2**: [Domain; Server list] Is it enough to print only active server or do we want full list of primary and backup servers as well? - Print full list containing also discovered servers. -- **Q3**: [Domain; Server list] Do we want to also print IP adresses? +- **Q3**: [Domain; Server list] Do we want to also print IP addresses? - Not needed. - **Q4**: [Talloc report] Should we provide parameter $file or should - we hardcod the path as SSSD logs directory, generating name from + we hardcode the path as SSSD logs directory, generating name from component and time? - Provide a file parameter but default to log directory. diff --git a/design_pages/subdomains.rst b/design_pages/subdomains.rst index 6aaa5f1..fae83d5 100644 --- a/design_pages/subdomains.rst +++ b/design_pages/subdomains.rst @@ -67,8 +67,8 @@ add sub-domain support to SSSD name of searched domain; second call get\_domains if domain cannot be found with force flag and name of searched domain) -The first task must be solved first but is only a minor effort.The other -two must wait on the first but also require some more work. +The first task must be solved first but is only a minor effort. The other +two must wait for the first but also require some more work. For the first implementation it is sufficient that sub-domains work only if the user name is fully qualified and that the domain name has to be diff --git a/design_pages/sudo_caching_rules.rst b/design_pages/sudo_caching_rules.rst index 6132a1b..c806144 100644 --- a/design_pages/sudo_caching_rules.rst +++ b/design_pages/sudo_caching_rules.rst @@ -102,7 +102,7 @@ A. Periodical download of changed or newly created rules (per host smart refresh #. refresh rules per host, where entryUSN > currentHighestUSN #. *sudoLastSmartRefreshTime* := current time - #. nextrefrest := (current time + + #. nextrefresh := (current time + *ldap\_sudo\_changed\_refresh\_interval*) #. **if** nextrefresh >= *sudoNextFullRefreshTime* AND nextrefresh < (*sudoNextFullRefreshTime* + diff --git a/design_pages/sudo_caching_rules_invalidate.rst b/design_pages/sudo_caching_rules_invalidate.rst index ebe39df..e4785b2 100644 --- a/design_pages/sudo_caching_rules_invalidate.rst +++ b/design_pages/sudo_caching_rules_invalidate.rst @@ -97,7 +97,7 @@ Implementation details A more technical extension of the previous section. Might include low-level details, such as C structures, function synopsis etc. In case -of very trivial features (e.g a new option), this section can be merged +of very trivial features (e.g. a new option), this section can be merged with the previous one. Configuration changes diff --git a/design_pages/sudo_integration.rst b/design_pages/sudo_integration.rst index bcec8db..912a8b4 100644 --- a/design_pages/sudo_integration.rst +++ b/design_pages/sudo_integration.rst @@ -5,7 +5,7 @@ SUDO plugin API --------------- Since version 1.8 SUDO supports replacing standard policy behaviour -usign plugins. +using plugins. Referral plugin API documentation can be found here: `http://www.gratisoft.us/sudo/man/1.8.2/sudo\_plugin.man.html `__ @@ -104,8 +104,8 @@ by SUDO) **user\_info** provided in open() function by SUDO (see plugin API open()) -Reponse -~~~~~~~ +Response +~~~~~~~~ Byte array with format: :: diff --git a/design_pages/sudo_ipa_schema.rst b/design_pages/sudo_ipa_schema.rst index 10131c2..6ea007c 100644 --- a/design_pages/sudo_ipa_schema.rst +++ b/design_pages/sudo_ipa_schema.rst @@ -76,7 +76,7 @@ This container contains definition of sudo rules. - *sudoNotBefore* ~ sudoNotBefore - *sudoOption* ~ sudoOption -The following attibures have a special meaning and can contain only +The following attributes have a special meaning and can contain only value "all". For example if cmdCategory is present, it is equivalent to sudoCommand=ALL. @@ -125,7 +125,7 @@ Smart refresh ^^^^^^^^^^^^^ - download everything under cn=sudo,$dc that applies to this host newer - than last usn value + than last USN value - if new command or command group is downloaded store it only if it is present in changed rule - if a rule contains command or command group that is not yet present diff --git a/design_pages/sudo_responder_cache_behaviour.rst b/design_pages/sudo_responder_cache_behaviour.rst index f10fbe2..4d878c0 100644 --- a/design_pages/sudo_responder_cache_behaviour.rst +++ b/design_pages/sudo_responder_cache_behaviour.rst @@ -14,26 +14,26 @@ information about sudo schema. 3. Each sudoRole object supports following attributes: - | **sudoUser** - A user name, uid (prefixed with '#'), Unix group + | **sudoUser** - A user name, uid (prefixed with '#'), UNIX group (prefixed with a '%') or user netgroup (prefixed with a '+'). | **sudoHost** - A host name, IP address, IP network, or host netgroup (prefixed with a '+'). The special value ALL will match any host. - | **sudoCommand** - A Unix command with optional command line + | **sudoCommand** - A UNIX command with optional command line arguments and wild chars. | **sudoOption** – Specifies options to be enabled or disabled as in the sudoers file. | **sudoRunAsUser** - A user name or uid (prefixed with '#') that - commands may be run as or a Unix group (prefixed with a '%') or + commands may be run as or a UNIX group (prefixed with a '%') or user netgroup (prefixed with a '+') that contains a list of users that commands may be run as. The special value ALL will match any user. - | **sudoRunAsGroup** - A Unix group or gid (prefixed with '#') that + | **sudoRunAsGroup** - A UNIX group or gid (prefixed with '#') that commands may be run as. The special value ALL will match any group. @@ -75,7 +75,7 @@ Q1). **What should we cache for offline sudo authentication???** The anatomy of sudo is as follows: when you type 'sudo cmd' sudo is going to lookup in ldap to try and - find the user posix groups and the user/host Nisnetgroup where the + find the user POSIX groups and the user/host Nisnetgroup where the user is a member. Then it is going to do an ldap search in the ou=SUDOers container looking for any rule that matches that user or his usergroups. when it matches some rules, it goes down that list @@ -88,7 +88,7 @@ Q1). **What should we cache for offline sudo authentication???** this anatomy. For the successful validation we need to know the nisnetgroups and - posix groups that a user/host is a member of. So that we need to + POSIX groups that a user/host is a member of. So that we need to cache the host/user-> nisgroup and user->posixgroups along with all sudoRole objects inside the SUDOers container that references to the specified command. @@ -103,7 +103,7 @@ Q1). **What should we cache for offline sudo authentication???** search in DN: cn=accounts,dc=example,dc=com. Here we can use memberof plugin to resolve the user groups and the host groups. This step is already implemented inside the sssd. In order to include the - support for nis net groups we can add one more filter to the query + support for NIS net groups we can add one more filter to the query that searches for the user groups. The query is :: (| @@ -114,7 +114,7 @@ Q1). **What should we cache for offline sudo authentication???** This will give you the netgroup that the user/host is a member of. - In the second phase we apply the search to filter the rules - that applies to the user/host posix groups and netgroups found + that applies to the user/host POSIX groups and netgroups found in step1. Search returns :: (\|(sudoBaseCommand=cmd)(sudoCommand=ALL)) where the diff --git a/design_pages/sudo_support.rst b/design_pages/sudo_support.rst index a64a161..3d6bd66 100644 --- a/design_pages/sudo_support.rst +++ b/design_pages/sudo_support.rst @@ -2,7 +2,7 @@ SUDO Support to SSSD ==================== This Design document talks about the integration of SUDO support to -SSSD through plugin system.The SUDO can be used to check whether a +SSSD through plugin system. The SUDO can be used to check whether a user have rights to execute the instructions as another user. Using this plugin SUDO can be configured to use custom rules and policies. So that we can alter authorization rules so as to provide cached @@ -62,7 +62,7 @@ SUDO Plugin The lightweight plugin just forwards the sudo command request from the SUDO utility to the SSSD. The plugin is made using the plugin-API and connected to the sudo utility at the client side. -When user types in the command with sudo (eg: sudo ls ) the sudo +When user types in the command with sudo (e.g.: sudo ls ) the sudo utility gives the chance for execution to the sudo plugin. The plugin calls the pam\_authenticate() from the pam library with pam service defined for sudo, to verify the user provided information. diff --git a/design_pages/sudo_support_plugin_wire_protocol.rst b/design_pages/sudo_support_plugin_wire_protocol.rst index 837d686..e524484 100644 --- a/design_pages/sudo_support_plugin_wire_protocol.rst +++ b/design_pages/sudo_support_plugin_wire_protocol.rst @@ -170,7 +170,7 @@ invalidate() The invalidate function is called when sudo is called with the -k or -K flag. This function will invalidate the credentials. i.e, the user credentials will be marked as invalid so that on the nest invocation of -sudo user will be forcefuilly prompted undergo the authentication +sudo user will be forcefully prompted undergo the authentication procedures. The invalidate function should be NULL if the plugin does not support credential caching. @@ -179,8 +179,8 @@ not support credential caching. @param[in] remove - If the remove flag is set, the plugin may remove the credentials instead of simply invalidating them. -Conversation API & Printf-style fuctions -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Conversation API & Printf-style functions +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ :: @@ -252,7 +252,7 @@ uint32\_t)+sizeof string } and integer type takes a space of { message\_type : is defined at "sss\_sudo\_cli.h" as **enum sudo\_item\_type** -The message foramt will be: :: +The message format will be: :: start_header + message_container1 + message_container2 + ........ + message_containerN + stop_header. @@ -302,6 +302,6 @@ The messages are: :: command SSS_SUDO_ITEM_COMMAND command with its arguments to be executed - user's enviroment variables SSS_SUDO_ITEM_USER_ENV null terminated list of environment variables + user's environment variables SSS_SUDO_ITEM_USER_ENV null terminated list of environment variables client pid SSS_SUDO_ITEM_CLI_PID client's pid diff --git a/design_pages/sysdb_fully_qualified_names.rst b/design_pages/sysdb_fully_qualified_names.rst index 0971af1..42aec99 100644 --- a/design_pages/sysdb_fully_qualified_names.rst +++ b/design_pages/sysdb_fully_qualified_names.rst @@ -22,7 +22,7 @@ There are two major problems with this approach: - For admins - The format of data in sysdb is dependent on SSSD configuration. Changes in sssd.conf may render the cached data invalid, so admins have to remove the cache. In general, allowing an - option that should purely control the ouput format to also control + option that should purely control the output format to also control the database layout is a very bad idea. - For code maintainers - The code that deals with SYSDB\_NAME attribute @@ -113,7 +113,7 @@ The sysdb upgrade is tricky for two reasons: plugin to allow the user to bypass the module (maybe when an environment variable is set) -Additionaly, because this update is risky, we should perform the update +Additionally, because this update is risky, we should perform the update on a copy of the database and only rename the copy when the upgrade finishes successfully. This would allow the admin to downgrade sssd back and still use the original database in the previous format. diff --git a/design_pages/systemd_activatable_responders.rst b/design_pages/systemd_activatable_responders.rst index 3c8b421..94098d9 100644 --- a/design_pages/systemd_activatable_responders.rst +++ b/design_pages/systemd_activatable_responders.rst @@ -263,7 +263,7 @@ will behave exactly as they did before these changes. How To Test ----------- -The easiest way to test is removing the service from sssd,conf's ``services`` +The easiest way to test is removing the service from sssd.conf's ``services`` line, enabling the service's socket and trying to use SSSD normally. See below an example of how to enable NSS and PAM sockets:: diff --git a/design_pages/use_ad_homedir.rst b/design_pages/use_ad_homedir.rst index 7bc122a..14cbab0 100644 --- a/design_pages/use_ad_homedir.rst +++ b/design_pages/use_ad_homedir.rst @@ -37,7 +37,7 @@ Implementation details SYSDB\_HOMEDIR attribute. - Update ``apply_subdomain_homedir()`` - - to parse AD home dirrctory from ldb\_msg + - to parse AD home directory from ldb\_msg - do not call ``store_homedir_of_user()`` if value of expanded home directory is an empty string. @@ -54,14 +54,14 @@ How To Test #. On SSSD in server mode - - For AD user with posix attributes set home directory attribute + - For AD user with POSIX attributes set home directory attribute - in sssd.conf set ``subdomain_homedir`` option to '%o' - invalidate cache (sss\_cache) and restart SSSD - call ``getent passwd user`` and check that home directory reflects value from AD - - For AD user ``without`` posix attributes + - For AD user ``without`` POSIX attributes - in sssd.conf set ``subdomain_homedir`` option to %o and ``fallback_homedir`` to /home/%u diff --git a/design_pages/usr_account_mgmt_consolidation.rst b/design_pages/usr_account_mgmt_consolidation.rst index adff662..412a596 100644 --- a/design_pages/usr_account_mgmt_consolidation.rst +++ b/design_pages/usr_account_mgmt_consolidation.rst @@ -103,7 +103,7 @@ Action Items - Test and implement Root only access to files, and channel all access through sssd - - Needed for openshift and similar containerized envs. + - Needed for OpenShift and similar containerized envs. Authors ~~~~~~~ diff --git a/design_pages/wildcard_refresh.rst b/design_pages/wildcard_refresh.rst index 4c76521..3f5b2a4 100644 --- a/design_pages/wildcard_refresh.rst +++ b/design_pages/wildcard_refresh.rst @@ -22,7 +22,7 @@ Use cases A web application, using the InfoPipe interface requests all users starting with the letter 'a' so the users can be displayed in the -application UI on a sigle page. The SSSD must fetch and return all +application UI on a single page. The SSSD must fetch and return all matching user entries, but without requiring enumeration, which would pull down too many users. @@ -168,9 +168,9 @@ parameter or even invert it along with renaming (i.e change the name to We also need to limit the number of entries returned from the server, otherwise the wildcard request might easily turn into a full enumeration. To this end, we will add a new configuration option -``wildcard_search_limit``. Internally, we would change the boolan +``wildcard_search_limit``. Internally, we would change the boolean parameter of ``sdap_get_users_send`` to a tri-state that would control -whether we expect only a single entry (ie don't use the paging control), +whether we expect only a single entry (i.e. don't use the paging control), multiple entries with a search limit (wildcard request) or multiple entries with no limit (enumeration). We need to make sure during implementation that it is discoverable via DEBUG messages that the upper @@ -233,7 +233,7 @@ supported. Making sure the IPA provider in server mode is capable of returning wildcard entries and adding a wildcard-enabled function for the -``libnss_sss_idmap`` library would a prerequisity so that the extop +``libnss_sss_idmap`` library would be a prerequisite so that the extop plugin can request multiple entries from the SSSD running in the server mode. @@ -269,7 +269,7 @@ How To Test When the InfoPipe API is ready, then testing will be done using the methods such as ListByName. Until then, the feature is not exposed or used anyway, so developers can test using a special command-line tool -that would send the DP request directly. This tool wouldn't be commited +that would send the DP request directly. This tool wouldn't be committed to the git tree. Authors diff --git a/developers/coding_style.rst b/developers/coding_style.rst index 8119c8b..798d2dd 100644 --- a/developers/coding_style.rst +++ b/developers/coding_style.rst @@ -85,7 +85,7 @@ Spaces and Indentation - after a comma - before an operator - - align the new line with the beginnigng of the expression at the + - align the new line with the beginning of the expression at the same level in the previous line - in case of long "if" statements, wrap the line before an operator and indent the new line diff --git a/developers/contribute.rst b/developers/contribute.rst index 607f33f..70194b0 100644 --- a/developers/contribute.rst +++ b/developers/contribute.rst @@ -43,7 +43,7 @@ source control system. :: https://pagure.io/SSSD/sssd.git -We also maintain a read-only mirror on github. :: +We also maintain a read-only mirror on GitHub. :: https://github.com/SSSD/sssd @@ -241,8 +241,8 @@ with the command: :: git add ... git commit -Before submitting a patch, always make sure it doesn't break SSSD -tests `_ +Before submitting a patch, always make sure it doesn't break `SSSD +tests `__ and applies to the latest upstream master branch. You will want to rebase to this branch and fix any merge conflicts (in case someone else changed the same code). :: @@ -264,10 +264,8 @@ Ticket #2789 `__ where one patch makes the ``resolv_is_address()`` function public with tests and the other adds the function in the SSSD providers. -.. FIXME: Add a link to GithubWorkflow as soon as it gets migrated. - -Once your changes are ready for submission, submit it via a github pull -request. +Once your changes are ready for submission, submit it via a `GitHub pull +request `__. If a patch isn't accepted on the first review, you will need to modify it and resubmit it. When this happens, you will want to amend your @@ -283,7 +281,7 @@ If you need to make changes to earlier patches in your tree, you can use :: and follow the directions in the interactive rebase to modify specific patches. -Then just re-push the patches to github, the pull request will be +Then just re-push the patches to GitHub, the pull request will be refreshed automatically. Patch metadata diff --git a/developers/ipc.rst b/developers/ipc.rst index e816698..f2de45e 100644 --- a/developers/ipc.rst +++ b/developers/ipc.rst @@ -2,7 +2,7 @@ Inter-process communication between SSSD processes ================================================== This document describes how the different SSSD processes communicate -between one another with a special epmhasis on the Sbus protocol. In +between one another with a special emphasis on the Sbus protocol. In addition, the document describes the interfaces SSSD might use to communicate with external libraries or programs, such as libkrb5 or how are the requests from NSS and PAM modules received. @@ -187,14 +187,14 @@ different circumstances: This means, there is ongoing sbus communication even though the sssd is otherwise idle. -Unix signals +UNIX signals ------------ Apart from the internal SBUS communication, SSSD also uses UNIX signals for certain functionality - either for communication with external utilities or for cases where the SBUS communication might not work, such as an unresponsive worker process. Below is an overview of the supported -signals and their use. The singal handlers are typically integrated with +signals and their use. The signal handlers are typically integrated with the tevent event loop using its ``tevent_add_signal`` call. SIGTERM diff --git a/developers/release_process.rst b/developers/release_process.rst index f2405fa..e6e34bc 100644 --- a/developers/release_process.rst +++ b/developers/release_process.rst @@ -33,7 +33,7 @@ Special Beta or Pre-release rules zanata-cli push -s . - #. If this is is the last pre-release (e.g. final beta before bugfix-only phase) String Freeze should be announced on the sssd-devel list and the Zanata site. + #. If this is the last pre-release (e.g. final beta before bugfix-only phase) String Freeze should be announced on the sssd-devel list and the Zanata site. Tag and sign the release ------------------------ @@ -42,7 +42,7 @@ Tag and sign the release git tag -s sssd-1_3_0 - #. Push the tag. Pus the tag explictly instead of using ``--tags`` so that you do not push extraneous tags by mistake:: + #. Push the tag. Push the tag explicitly instead of using ``--tags`` so that you do not push extraneous tags by mistake:: git push origin sssd-1_3_0 @@ -141,7 +141,7 @@ Update the releases page git diff previoustag..newtag -- contrib/sssd.spec.in - #. For each release, if any changes have occured in documentation, such as new options, options changing default values, the release notes should include a section that summarizes there changes:: + #. For each release, if any changes have occurred in documentation, such as new options, options changing default values, the release notes should include a section that summarizes there changes:: git diff previoustag..newtag -- src/man diff --git a/newcomers/getting_started.rst b/newcomers/getting_started.rst index 651bd6d..db32ffe 100644 --- a/newcomers/getting_started.rst +++ b/newcomers/getting_started.rst @@ -69,9 +69,9 @@ So, the first thing to contribute to SSSD is forking our `GitHub In order to do so, go to our `SSSD's github page `__, log in with your GitHub account and click in the ``Fork`` button. It will create a sssd fork in your -own github account. Once it's done ... +own GitHub account. Once it's done ... -- Clone your own SSSD's fork: +- Clone your own SSSD fork: ``$ git clone git@github.com:/sssd.git`` - Add `SSSD's github repo `__ as a @@ -87,18 +87,18 @@ in our `Contribute page `__ , have made your changes following our `Coding guidelines `__ and -have commited your changes following our `git-commit-template +have committed your changes following our `git-commit-template `__ and have implemented some unit/integration tests to ensure we're never hit -this very same issue again in the future ... now is time to open your +by this very same issue again in the future ... now is time to open your pull-request. -The way the author of this documment does is: +The way the author of this document does is: -- Push the changes to *your* SSSD's repo: +- Push the changes to *your* SSSD repo: ``$ git push origin wip/meaningful_name`` -- Go to yours GitHub page; +- Go to your GitHub page; - Open the Pull Request by using GitHub's web UI. @@ -129,7 +129,7 @@ Once your code is reviewed, a few different things may happen: merged to SSSD's repo without any changes. - Changes are requested: it means that something has to be changed in - your patch before it gets merged to SSSD; s repo. In this case, + your patch before it gets merged to SSSD's repo. In this case, you'd like to: - Carefully read and understand the changes required by the reviewer; @@ -142,7 +142,7 @@ Once your code is reviewed, a few different things may happen: - Please, do *not* privately ping the developers for all your doubts. Discussing in the pull-request is a better and more transparent way to do so *and* also doesn't interrupt the - developr from any other task they are doing. + developer from any other task they are doing. - Make the changes in your patches; diff --git a/users/ad_provider.rst b/users/ad_provider.rst index 167c711..b586419 100644 --- a/users/ad_provider.rst +++ b/users/ad_provider.rst @@ -100,7 +100,7 @@ use ``ldap_id_mapping=False`` instead. * In general, search for a user entry that has the POSIX attributes set on port 3268 of a Domain Controller - * You can use the LDP tool from Windows or later, when the Linux machine + * You can use the LDP tool from Windows or later, when the GNU/Linux machine is joined, simply ``ldapsearch`` Client configuration @@ -115,7 +115,7 @@ configuration. Let's take a look at the automated procedure first. DNS configuration ^^^^^^^^^^^^^^^^^ -It is recommended that the Linux client you are enrolling is able to +It is recommended that the GNU/Linux client you are enrolling is able to resolve the SRV records the Active directory publishes. In order to do so, the clients would typically point at the AD DCs in ``/etc/resolv.conf``. You can verify this using dig:: @@ -129,12 +129,12 @@ are not reachable, either exclude that domain with ``ad_enabled_domains`` or, if only some DCs from that trusted domain are reachable, define a per-subdomain section in the config file (see below for an example). -Joining the Linux client using realmd -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Joining the GNU/Linux client using realmd +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The realmd (Realm Discovery) project is a system service that manages discovery and enrolment to several centralized domains including AD or -IPA. realmd is included in several popular Linux distributions including: +IPA. realmd is included in several popular GNU/Linux distributions including: * Red Hat Enterprise Linux 7.0 and later * Fedora 19 and later @@ -176,7 +176,7 @@ directly-enrolled AD client machine. * Pros: Very simple. Supports nested groups, because the user entry is fully evaluated on login first and then the simple access provider runs. - * Cons: Does not support any more expresiveness than allow/deny a + * Cons: Does not support any more expressiveness than allow/deny a user or a group. * ``access_provider=ad`` @@ -184,7 +184,7 @@ directly-enrolled AD client machine. * Pros: Supports fully centralized environments by using GPOs for access control * Cons: Not supported with older releases. In a mixed environment, - sometimes using the same options for Linux and Windows machines might + sometimes using the same options for GNU/Linux and Windows machines might not be desirable. * ``ad_access_filter`` @@ -200,10 +200,10 @@ such as ``pam_access.so``. Those might be useful when supporting legacy stack alongside SSSD or when defining access control by means SSSD doesn't support (such as per netgroup). -Joining the Linux client to the AD domain manually -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Joining the GNU/Linux client to the AD domain manually +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -The manual process of joining the Linux client to the AD domain consists +The manual process of joining the GNU/Linux client to the AD domain consists of several steps: * Acquiring the host keytab with Samba or create it using ``ktpass`` on the @@ -215,11 +215,11 @@ of several steps: Creating Host Keytab with Samba """"""""""""""""""""""""""""""" -On the Linux client with properly configured ``/etc/krb5.conf`` (see below) +On the GNU/Linux client with properly configured ``/etc/krb5.conf`` (see below) and suitable ``/etc/samba/smb.conf``: /etc/krb5.conf -"""""""""""""" +'''''''''''''' Adjust the contents to match your realm data:: @@ -355,7 +355,7 @@ SSSD setup Configuring SSSD consists of several steps: -* Install the ``sssd-ad`` package on the Linux client machine +* Install the ``sssd-ad`` package on the GNU/Linux client machine * Make configuration changes to the files below * Start the ``sssd`` service @@ -501,7 +501,7 @@ Right after the ``pam_unix.so`` line, add:: Understanding Kerberos & Active Directory ----------------------------------------- -It is important to understand that (unlike Linux MIT based KDC) Active +It is important to understand that (unlike GNU/Linux MIT based KDC) Active Directory based KDC divides Kerberos principals into two groups: * *User Principals* - usually equals to the ``sAMAccountname`` attribute of @@ -542,7 +542,7 @@ on the network with network access to the AD servers:: service sssd start getent passwd administrator@ad.example.com -f all looks well on your system after this, you know that sssd is able o +If all looks well on your system after this, you know that sssd is able o use the kerberos and ldap services you've configured. The example configuration enforces the use of *fully qualified names*. diff --git a/users/faq.rst b/users/faq.rst index 2d406eb..0bcb076 100644 --- a/users/faq.rst +++ b/users/faq.rst @@ -19,7 +19,7 @@ Daemon `__ What platforms run SSSD? ^^^^^^^^^^^^^^^^^^^^^^^^ -We are currently aware of the following Linux distributions shipping +We are currently aware of the following GNU/Linux distributions shipping some version of SSSD. - `Fedora Project `__ - This is the @@ -35,7 +35,7 @@ some version of SSSD. `AUR `__ In theory, SSSD should compile and run (hopefully without modification) -on any modern Linux distribution. Non-Linux platforms such as the BSD +on any modern GNU/Linux distribution. Non-Linux platforms such as the BSD distributions are not yet fully supported, though some work is ongoing to port SSSD to `FreeBSD `__ @@ -51,7 +51,7 @@ one LTM branch at the same time. The branches designated as LTM (long-term maintenance) are supported for longer time than other releases with fixes for important bugs and security patches. -The regular releases are more frequent than LTM releases and are intened +The regular releases are more frequent than LTM releases and are intended for users who like to use the latest functionality. The LTM releases are targeted at users who prefer to run very stable codebase and don't need the latest features. @@ -139,7 +139,7 @@ support this feature on the server side either. What LDAP schema should I use? ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -The LDAP schema defines the set of default attribute names retreived on +The LDAP schema defines the set of default attribute names retrieved on the server as well as meaning of some of the attributes, notably membership attributes. The two most widely used schemas are rfc2307 and rfc2307bis with rfc2307 being the default. When using the rfc2307 diff --git a/users/ldap_with_ad.rst b/users/ldap_with_ad.rst index 371183b..38a8933 100644 --- a/users/ldap_with_ad.rst +++ b/users/ldap_with_ad.rst @@ -10,7 +10,7 @@ It is recommended to use the AD provider when connecting to an AD server, for performance and ease of use reasons. Please see :doc:`ad_provider` for a reference. There are two reasons where you might still want to use the LDAP provider, though. One is if you are using a *very* old SSSD version, -the other reason is if you cannot or do not want join your Linux clients +the other reason is if you cannot or do not want join your GNU/Linux clients to the AD domain. Windows Server Setup @@ -57,7 +57,7 @@ this with Samba, or using Windows. Samba is recommended. Creating Service Keytab with Samba """""""""""""""""""""""""""""""""" -On the Linux client with properly configured ``/etc/krb5.conf`` (see +On the GNU/Linux client with properly configured ``/etc/krb5.conf`` (see below) and suitable ``/etc/samba/smb.conf``:: [global] @@ -109,7 +109,7 @@ On the Windows server: # chmod 0600 /etc/krb5.keytab # restorecon /etc/krb5.keytab -See the ``Linux Client Setup`` section for verifying the keytab file and +See the ``GNU/Linux Client Setup`` section for verifying the keytab file and the example sssd.conf below for the needed SSSD configuration. Using DN/Password Binds for LDAP Searches @@ -145,10 +145,10 @@ Adding a User - Set the ``Home Directory`` to ``/home/aduser`` - Set ``Primary Group Name/GID`` to ``unixusers`` -Linux Client Setup ------------------- +GNU/Linux Client Setup +---------------------- -- Install ``sssd`` package on the Linux client machine +- Install ``sssd`` package on the GNU/Linux client machine - Make configuration changes to the files below - Start the ``sssd`` service @@ -197,7 +197,7 @@ properly:: If you generated your keytab with a different createupn argument, it's possible this won't work and the following works instead. This is absolutely fine as far as sssd is concerned, and you can instead generate a ticket -for the upn you have created:: +for the UPN you have created:: # kinit -k -t /etc/krb5.keytab nfs/client.ad.example.com@AD.EXAMPLE.COM @@ -213,8 +213,8 @@ has sufficient rights to retrieve user information. After both ``kinit`` and ``ldapsearch`` work properly proceed to actual SSSD configuration. -``/etc/sssd/sssd.conf`` -^^^^^^^^^^^^^^^^^^^^^^^ +/etc/sssd/sssd.conf +^^^^^^^^^^^^^^^^^^^ Example ``sssd.conf`` configuration, additional options can be added as needed:: @@ -388,7 +388,7 @@ Right after the ``pam_unix.so`` line, add:: Understanding Kerberos & Active Directory ----------------------------------------- -It is important to understand that (unlike Linux MIT based KDC) Active +It is important to understand that (unlike GNU/Linux MIT based KDC) Active Directory based KDC divides Kerberos principals into two groups: - *User Principals* - usually equals to the sAMAccountname attribute of diff --git a/users/relnotes/notes_1_13_0.rst b/users/relnotes/notes_1_13_0.rst index 47adeae..75be1ff 100644 --- a/users/relnotes/notes_1_13_0.rst +++ b/users/relnotes/notes_1_13_0.rst @@ -376,7 +376,7 @@ Pavel Březina (53): - cache\_req tests: rename test\_user to test\_user\_by\_name - cache\_req tests: define user name constant - cache\_req: preparations for different input type -- cache\_req: add support for user by uid +- cache\_req: add support for user by UID - cache\_req: add support for group by name - cache\_req: remove default branch from switches - cache\_req: add support for group by id diff --git a/users/relnotes/notes_1_13_2.rst b/users/relnotes/notes_1_13_2.rst index a500822..8e513c9 100644 --- a/users/relnotes/notes_1_13_2.rst +++ b/users/relnotes/notes_1_13_2.rst @@ -16,7 +16,7 @@ Highlights - A socket leak in case SSSD couldn't establish a connection to an LDAP server was fixed - SSSD's memory cache now behaves better when used by long-running - applications such as system deamons and the administrator invalidates + applications such as system daemons and the administrator invalidates the cache - The SSSDConfig Python API no longer throws an exception when config\_file\_version is missing diff --git a/users/relnotes/notes_1_13_4.rst b/users/relnotes/notes_1_13_4.rst index 61d4ae2..eeafc9e 100644 --- a/users/relnotes/notes_1_13_4.rst +++ b/users/relnotes/notes_1_13_4.rst @@ -58,7 +58,7 @@ Documentation Changes a high RID values. Most deployments can use the default value of this option. - Several PAM services were added to the lists that are used to map - Windows logon services to Linux PAM services. The newly added PAM + Windows logon services to GNU/Linux PAM services. The newly added PAM services include login managers (``lightdm``, ``lxdm``, ``sddm`` and ``xdm``) as well as the ``cockpit`` service. - The AD machine credentials renewal task can be fine-tuned using the diff --git a/users/relnotes/notes_1_16_0.rst b/users/relnotes/notes_1_16_0.rst index 2708818..61ccecd 100644 --- a/users/relnotes/notes_1_16_0.rst +++ b/users/relnotes/notes_1_16_0.rst @@ -206,8 +206,8 @@ Detailed Changelog * NEGCACHE: Descend to all subdomains when adding user/groups * CACHE_REQ: Don't error out when searching by id = 0 * NSS: Don't error out when deleting an entry which has id = 0 from the memcache - * NEGCACHE: Add root's uid/gid to ncache - * TEST_NEGCACHE: Ensure root's uid and gid are always added to ncache + * NEGCACHE: Add root's UID/GID to ncache + * TEST_NEGCACHE: Ensure root's UID and GID are always added to ncache * CONFDB: Set a default value for subdomain_refresh_interval in case an invalid value is set * SDAP: Add a debug message to explain why a backend was marked offline * SDAP: Don't call be_mark_offline() because sdap_id_conn_data_set_expire_timer() failed diff --git a/users/sudo_troubleshooting.rst b/users/sudo_troubleshooting.rst index 48721e3..265ee49 100644 --- a/users/sudo_troubleshooting.rst +++ b/users/sudo_troubleshooting.rst @@ -70,7 +70,7 @@ What to look for in the logs ldbsearch -H /var/lib/sss/db/cache_$domain.ldb -b cn=sysdb '$filter' -- SSSD cache uses LDAP-like format equal to sudo format descibred in +- SSSD cache uses LDAP-like format equal to sudo format described in `man sudoers.ldap `__ @@ -86,7 +86,7 @@ What to look for in the logs - Were all matching rules stored? :: - [sdap_sudo_refresh_load_done] (0x0400): Sudoers is successfuly stored in cache + [sdap_sudo_refresh_load_done] (0x0400): Sudoers is successfully stored in cache - What filter was used to fetch rules from server? :: @@ -165,7 +165,7 @@ Common questions **a) Setting global options with cn=defaults when sudo rules are stored on an IPA server** -To immitate global options, create a rule named ``cn=defaults`` in LDAP tree +To imitate global options, create a rule named ``cn=defaults`` in LDAP tree or rule named ``defaults`` in IPA and ``set`` sudoOption attribute as you wish. **b) !authenticate does not work** @@ -225,7 +225,7 @@ IPA provider** We switched to IPA sudo rules schema stored at ``cn=sudo`` in SSSD 1.13.4. The slapi-nis plugin that is used to generate the compat tree -``ou=sudoers`` unfold members of non-posix group and stores each as +``ou=sudoers`` unfold members of non-POSIX group and stores each as ``sudoUser: member`` value. This makes sudo rules work even with non-POSIX group if the compat tree is used. @@ -235,7 +235,7 @@ from the compat tree again by setting ``ldap_sudo_search_base`` to The correct way to reference a non-POSIX group in sudo rule is to include it by a POSIX one which is referenced by sudo as "sudorule ---> -posix group <--- non-posix group". +POSIX group <--- non-POSIX group". Asking for help --------------- diff --git a/users/troubleshooting.rst b/users/troubleshooting.rst index 5c64b39..faced5c 100644 --- a/users/troubleshooting.rst +++ b/users/troubleshooting.rst @@ -11,7 +11,7 @@ in a :doc:`bug report ` or on the `user support list