Some distributions, notably Fedora, have the following order of nsswitch
modules by default:
passwd: sss files
group: sss files
The advantage of serving local users through SSSD is that the nss_sss
module has a fast mmapped-cache that speeds up NSS lookups compared to
accessing the disk an opening the files on each NSS request.
Traditionally, this has been done with the help of nscd, but using nscd
in parallel with sssd is cumbersome, as both SSSD and nscd use their own
independent caching, so using nscd in setups where sssd is also serving
users from some remote domain (LDAP, AD, ...) can result in a bit of
unpredictability.
More details about why Fedora chose to use sss before files can be found
on e.g.:
https://fedoraproject.org//wiki/Changes/SSSDCacheForLocalUsers
or:
https://docs.pagure.org/SSSD.sssd/design_pages/files_provider.html
Now, even though sssd watches the passwd and group files with the help
of inotify, there can still be a small window where someone requests a
user or a group, finds that it doesn't exist, adds the entry and checks
again. Without some support in shadow-utils that would explicitly drop
the sssd caches, the inotify watch can fire a little late, so a
combination of commands like this:
getent passwd user || useradd user; getent passwd user
can result in the second getent passwd not finding the newly added user
as the racy behaviour might still return the cached negative hit from
the first getent passwd.
This patch more or less copies the already existing support that
shadow-utils had for dropping nscd caches, except using the "sss_cache"
tool that sssd ships.
The third field in the /etc/shadow file (sp_lstchg) contains the date of
the last password change expressed as the number of days since Jan 1, 1970.
As this is a relative time, creating a user today will result in:
username:17238:0:99999:7:::
whilst creating the same user tomorrow will result in:
username:17239:0:99999:7:::
This has an impact for the Reproducible Builds[0] project where we aim to
be independent of as many elements the build environment as possible,
including the current date.
This patch changes the behaviour to use the SOURCE_DATE_EPOCH[1]
environment variable (instead of Jan 1, 1970) if valid.
[0] https://reproducible-builds.org/
[1] https://reproducible-builds.org/specs/source-date-epoch/
Signed-off-by: Chris Lamb <lamby@debian.org>
If ptr->line == NULL for an entry, the first cycle will exit,
but the second one will happily write past entries buffer.
We actually do not want to exit the first cycle prematurely
on ptr->line == NULL.
Signed-off-by: Tomas Mraz <tmraz@fedoraproject.org>
Without this patch, PAM enabled builds crash when encountering an
invalid key in login.defs or key overrides because of array overflows
To reproduce, simply
useradd -K Windows=broken
Signed-off-by: Bernhard Rosenkränzer <bero@lindev.ch>
Signed-off-by: Serge Hallyn <serge@hallyn.com>
Otherwise we get build warnings like:
sgroupio.c:255:6: warning: implicit declaration of function 'getdef_bool' [-Wimplicit-function-declaration]
shadowio.c:131:6: warning: implicit declaration of function 'getdef_bool' [-Wimplicit-function-declaration]
The functions __gr_dup and __pw_dup do not explicitly zero the
memory which hold the passwords after free. The gr_free and pw_free
functions do this explicitly.
To guarantee same behaviour, it's possible to call these *_free
functions directly from __*_dup, because the memory is initialized
with zeros at the beginning. Calling free(NULL) has no negative
effect and can be considered safe these days.
When compiled with PAM certain settings are not used, however they are
still defined in the stock login.defs file. Thus every command reports
them as "unknown setting contact administrator".
Alternative would be to parse stock login.defs and comment out/remove
settings that are not applied, when compiled with PAM.
Change suggested by Nicolas François as performance optimization.
Performance penalty would be really noticeable when usernames are
stored in remote databases (ldap).
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
Until now only exact username specification in /etc/sub[ug]id file allowed the
mapping. This prevented normal use for those users who use multiple usernames
with the same UID, as it rejected mapping even though it was allowed for
another username with the same UID.
This patch initially retains the old behaviour, for performance's sake. In the
first pass, new[ug]idmap only searches for exact username match.
If that yields no valid results, it continues into another loop, which does UID
resolution and comparison. If either definition (numeric UID mapping
specification or mapping specification for another username with the same UID as
current username) is found, it is used.
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
* libmisc/find_new_sub_gids.c: Remove dead code.
find_new_sub_gids() is always called with *range_count set to 0.
It's more difficult to keep the subordinate GIDs and UIDs
synchronized, than for the user's UID/GId because the count of
subordinate IDs may differ.
* libmisc/find_new_sub_uids.c: Likewise.
* lib/subordinateio.h, lib/subordinateio.c: Remove APIs that are
no more needed: is_sub_uid_range_free(), is_sub_gid_range_free(),
is_range_free().
* configure.in: Add configure options --enable-subordinate-ids /
--disable-subordinate-ids. Enabled by default.
* lib/prototypes.h: Include <config.h> before using its macros.
* lib/commonio.h, lib/commonio.c: Define commonio_append only when
ENABLE_SUBIDS is defined.
* lib/prototypes.h, libmisc/find_new_sub_gids.c,
libmisc/find_new_sub_uids.c: Likewise.
* lib/subordinateio.h, lib/subordinateio.c: Likewise.
* libmisc/user_busy.c: Only check if subordinate IDs are in use if
ENABLE_SUBIDS is defined.
* src/Makefile.am: Create newgidmap and newuidmap only if
ENABLE_SUBIDS is defined.
* src/newusers.c: Check for ENABLE_SUBIDS to enable support for
subordinate IDs.
* src/useradd.c: Likewise.
* src/userdel.c: Likewise.
* src/usermod.c: Likewise.
* man/Makefile.am: Install man1/newgidmap.1, man1/newuidmap.1,
man5/subgid.5, and man5/subuid.5 only if ENABLE_SUBIDS is defined.
* man/fr/Makefile.am: Install man1/newgidmap.1, man1/newuidmap.1,
man5/subgid.5, and man5/subuid.5 (not translated yet).
* man/generate_mans.mak: Add xsltproc conditionals
subids/no_subids.
* man/login.defs.d/SUB_GID_COUNT.xml: Add dependency on subids
condition.
* man/login.defs.d/SUB_UID_COUNT.xml: Likewise.
* man/usermod.8.xml: Document options for subordinate IDs and
reference subgid(5) / subuid(5) depending on the subids condition.
* lib/groupmem.c (__gr_dup): Support libc which define other
fields in struct group.
* lib/pwmem.c: Likewise for struct passwd.
* lib/shadowmem.c: Likewise for struct spwd.
* lib/sgroupio.c: Apply same logic, even if this structure is
defined internally.
subordinate_parse is supposed to return a static structure that
represents one line in /etc/subuid or /etc/subgid. I goofed and
failed to make the variable rangebuf that holds the username of
in the returned structure static.
Add this missing static specification.
Author: <Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
These files list the set of subordinate uids and gids that users are allowed
to use. The expect use case is with the user namespace but other uses are
allowed.
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
To support files that do not have a simple unique key implement
commonio_append to allow new entries to be added.
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Review b10cba0e0a and 7a16f4582d:
* lib/groupio.c (merge_group_entries): Do not allocate more than
necessary (sizeof char* instead of char).
Thanks for Tomáš Mráz (alioth#313962)
* lib/groupio.c (merge_group_entries): Document that new_members
is correctly NULL terminated. (alioth:#313940)
Align previous ChangeLog entries.
* Changelog: Update documentation of 2013-07-28 mancha entry.
* lib/prototypes.h, lib/encrypt.c: Update splint marker,
pw_encrypt can return NULL.
* lib/encrypt.c: Fix outdated statement on GNU crypt.
* src/chgpasswd.c: Improve diagnostic to user when pw_encrypt
fails and use fail_exit() instead of exit().
* src/chpasswd.c: Likewise.
* src/newusers.c: Likewise.
* src/passwd.c: Likewise when new password is encrypted.
* src/newgrp.c: Improve diagnostic to user and syslog when
pw_encrypt fails. Do not apply 1s penalty as this is not an
invalid password issue.
* src/passwd.c: Likewise when password is checked.
