The typedef security_context_t is deprecated, see
9eb9c93275
Signed-off-by: Christian Göttsche <cgzones@googlemail.com>
Acked-by: James Carter <jwcart2@gmail.com>
covscan issue:
Error: RESOURCE_LEAK (CWE-772): [#def39] [important]
src/useradd.c:728: alloc_fn: Storage is returned from allocation function "get_local_group".
src/useradd.c:728: var_assign: Assigning: "grp" = storage returned from "get_local_group(list)".
src/useradd.c:728: overwrite_var: Overwriting "grp" in "grp = get_local_group(list)" leaks the storage that "grp" points to.
726| * GID values, otherwise the string is looked up as is.
727| */
728|-> grp = get_local_group (list);
729|
730| /*
Although it is a good idea to check for an inadvertent typo
in the shell name it is possible that the shell might not be present
on the system yet when the user is added.
This option can be used to set a separate mode for useradd(8) and
newusers(8) to create the home directories with.
If this option is not set, the current behavior of using UMASK
or the default umask is preserved.
There are many distributions that set UMASK to 077 by default just
to create home directories not readable by others and use things like
/etc/profile, bashrc or sudo configuration files to set a less
restrictive
umask. This has always resulted in bug reports because it is hard
to follow as users tend to change files like bashrc and are not about
setting the umask to counteract the umask set in /etc/login.defs.
A recent change in sudo has also resulted in many bug reports about
this. sudo now tries to respect the umask set by pam modules and on
systems where pam does not set a umask, the login.defs UMASK value is
used.
This commit adds a from= field to the end of the useradd log entry.
Casting user_name to tallylog_reset to silence a compiler warning.
Changelog: Fixing tabs
Changelog: Changing function prototype to const char* to match user_name declaration.
This option can be used to set a separate mode for useradd(8) and
newusers(8) to create the home directories with.
If this option is not set, the current behavior of using UMASK
or the default umask is preserved.
There are many distributions that set UMASK to 077 by default just
to create home directories not readable by others and use things like
/etc/profile, bashrc or sudo configuration files to set a less
restrictive
umask. This has always resulted in bug reports because it is hard
to follow as users tend to change files like bashrc and are not about
setting the umask to counteract the umask set in /etc/login.defs.
A recent change in sudo has also resulted in many bug reports about
this. sudo now tries to respect the umask set by pam modules and on
systems where pam does not set a umask, the login.defs UMASK value is
used.
new switch added to useradd command, --btrfs-subvolume-home. When
specified *and* the filesystem is detected as btrfs, it will create a
subvolume for user's home instead of a plain directory. This is done via
`btrfs subvolume` command. Specifying the new switch while trying to
create home on non-btrfs will result in an error.
userdel -r will handle and remove this subvolume transparently via
`btrfs subvolume` command. Previosuly this failed as you can't rmdir a
subvolume.
usermod, when moving user's home across devices, will detect if the home
is a subvolume and issue an error messages instead of copying it. Moving
user's home (as subvolume) on same btrfs works transparently.
As the large uids are usually provided by remote user identity and
authentication service, which also provide user login tracking,
there is no need to create a huge sparse file for them on every local
machine.
fixup! login.defs: Add LASTLOG_UID_MAX variable to limit lastlog to small uids.
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.
Equivalent of `mkdir -p`. It will create all parent directories.
Example: `useradd -d /home2/testu1 -m testu1`
Based on https://github.com/shadow-maint/shadow/pull/2 by Thorsten Kukuk
and Thorsten Behrens which was Code from pwdutils 3.2.2 with slight adaptations.
Adapted to so it applies to current code.
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>
This reverts the behavior of "useradd --root" to using the settings
from login.defs in the target root directory, not the root of the
executed useradd command.
