Accepting numeric UID, GID, supplementary GIDs as expression output?
AssignUserIDExpr
/AssignGroupIDExpr
must return a username/groupname and all additional required information (the numeric UID/primary GID as well as numeric GID of all further groups which the user is a member of) is queried with the getpwnam.3
syscall.
Instead, the module could evaluate expressions to directly retrieve the numeric IDs.
Fully bypassing the entity database is error-prone. However, resolving the required information can be made architecturally simpler in complex set-ups where user information is made available to the entity database via nss connecting to sssd connecting to LDAP. To fully bypass the entity database, all numeric IDs (UID, primary GID, supplementary GIDs) must be made available directly.
Notes on possible implementation:
- Configuration directive for switching the resolution backend, the default being the current behaviour of evaluating
AssignUserID
,AssignUserIDExpr
, ... and resolving missing information via entity database. - For the entity database backend,
getpwuid
can be executed to check whether the user exists and retrieve additional information. E.g. the supplementary groups always have to be looked up, see #12 (closed). - Alternatively, have a resolution backend where all IDs are specified directly as expressions.
- This backend could reuse some of the
Assign...
directives or set up its own. - Supplementary GIDs have to be specified as a list of numbers which may be separated by
,
, ... - Fortunately, parsing a list of IDs is much simpler than parsing a list of user names/group names, which do not follow a standardised format.
- The existing
AssignUserIDExpr
could be modified to also accept a numeric ID e.g. in the format of#<numeric>
or if thegetpwnam
lookup fails and the expression evaluates to a string which can be converted to an integer, assume that this is a numeric ID. - The current single step of querying and setting supplementary group IDs via
initgroups.3
could be split into a querying step usinggetgrouplist.3
(not standardised) orgetgrent.3
(standardised) and a setting step usingsetgroups.2
.