The autoconf/automake guys want AC_INIT to be passed the details of the
package directly rather than going through AM_INIT_AUTOMAKE. Update them
both to use the newer style.
This also allows us to pass in contact details for the project.
We set the minimum autoconf version to 2.64 as that's the first one to
support passing the homepage URL in to AC_INIT. That's a pretty old
release by now, so it shouldn't be a problem.
These assignments were pasted as is into the Makefile and
ended up as part of a rule. (Usually the .PRECIOUS rule
which is why the build system never attempted to execute it
as commands, hiding the problem.)
Signed-off-by: Wolfgang Bumiller <wry.git@bumiller.com> Reported-by: Rahel A <ra00177@surrey.ac.uk>
Michael Vetter [Mon, 18 Jul 2016 13:18:08 +0000 (15:18 +0200)]
Fix sentence in usermod manual
Should have been: '[...] but only checkS [...]'.
So there was a missing 's'. Architectures isn't the right word either.
I decided to write the whole sentence new.
Some of the supplied tools use functions which are not signal-safe.
Most of the times it's exit() vs. _exit().
In other times it's how the standard output or standard error is
handled. FILE-related functions shall be avoided, therefore I replaced
them with write().
Also there is no need to call closelog(). At worst, it allows to
trigger a deadlock by issuing different signal types at bad timings.
But as these fixes are about race conditions, expect bad timings in
general for these bugs to be triggered. :)
Tomas Mraz [Thu, 3 Mar 2016 14:37:01 +0000 (15:37 +0100)]
Add ability to clear or set lastlog record for user via lastlog command
This functionality is useful because there is now a feature
of Linux-PAM's pam_lastlog module to block expired users (users
which did not login recently enough) from login. This commit
complements it so the sysadmin is able to unblock such expired user.
Signed-off-by: Tomáš Mráz <tmraz@fedoraproject.org>
Serge Hallyn [Thu, 18 Feb 2016 17:20:43 +0000 (09:20 -0800)]
useradd: respect -r flag when allocating subuids
We intend to not create subuids for system users. However we are
checking for command line flags after we check whether -r flag
was set, so it was never found to be true. Fix that.
Stéphane Graber [Mon, 15 Feb 2016 23:11:10 +0000 (18:11 -0500)]
Tweak uid/gid map default configuration
- Use an allocation of 65536 uids and gids to allow for POSIX-compliant
user owned namespaces.
- Don't allocate a uid/gid map to system users.
Unfortunately checking for --system isn't quite enough as some
distribution wrappers always call useradd without --system and take care
of choosing a uid and gid themselves, so also check whether the
requested uid/gid is in the user range.
This is taken from a patch I wrote for Ubuntu a couple years ago and
which somehow didn't make it upstream.
The current implementation of subuid/subgid support in usermod requires the
user to be a local user present in /etc/passwd. There doesn't seem to be a
good reason for this; subuids should work equally well for users whose
records are in other NSS databases.
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.
Allow deleting the group even if it is the primary group of a user
This is helpful when using configuration management tools such as
Puppet, where you are managing the groups in a central location and you
don't need this safeguard.
Signed-off-by: "Jesse W. Hathaway" <jesse@mbuki-mvuki.org> Acked-by: Serge Hallyn <serge.hallyn@ubuntu.com>
Expand the error message when newuidmap / newgidmap do not like the user/group ownership of their target process.
Currently the error is just:
newuidmap: Target [pid] is owned by a different user
With this patch it will be like:
newuidmap: Target [pid] is owned by a different user: uid:0 pw_uid:0 st_uid:0, gid:0 pw_gid:0 st_gid:99
Why is this useful? Well, in my case...
The grsecurity kernel-hardening patch includes an option to make parts
of /proc unreadable, such as /proc/pid/ dirs for processes not owned by
the current uid. This comes with an option to make /proc/pid/
directories readable by a specific gid; sysadmins and the like are then
put into that group so they can see a full 'ps'.
This means that the check in new[ug]idmap fails, as in the above quoted
error - /proc/[targetpid] is owned by root, but the group is 99 so that
users in group 99 can see the process.
Some Googling finds dozens of people hitting this problem, but not
*knowing* that they have hit this problem, because the errors and
circumstances are non-obvious.
Some graceful way of handling this and not failing, will be next ;) But
in the meantime it'd be nice to have new[ug]idmap emit a more useful
error, so that it's easier to troubleshoot.
Do not fail on missing files in /etc/, create them instead.
passwd, shadow, group, gshadow etc. can be managed via nss -
e.g. system default accounts can be specified using nss_altfiles,
rather than in /etc/. Thus despite having default accounts, these
files can be missing on disk and thus should be opened with O_CREATE
whenever they are attempted to be opened in O_RDWR modes.
Do not report unknown settings, when compiled with PAM.
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.
Duncan Eastoe [Mon, 9 Feb 2015 14:39:31 +0000 (14:39 +0000)]
Suppress pwconv passwd- chmod failure message
Prevent chmod failure message from displaying if the failure
was due to the backup file not existing.
If there is no backup file present and if no changes have been
made, then this error would always appear since the backup
file isn't created in this situation.
sub[ug]id: compare range before comparing username/UID, to avoid unnecessary syscalls
Change suggested by Nicolas François as performance optimization.
Performance penalty would be really noticeable when usernames are
stored in remote databases (ldap).
newuidmap/newgidmap: added support for user matching by UID in /etc/sub[ug]id
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.
projects / shadow / log