Tomas Mraz [Thu, 2 May 2019 12:39:01 +0000 (14:39 +0200)]
Do not fail locking if there is a stale lockfile.
As the lockfiles have PID in the name, there can be no conflict
in the name with other process, so there is no point in using
O_EXCL and it only can fail if there is a stale lockfile from
previous execution that crashed for some reason.
Tomas Mraz [Thu, 2 May 2019 12:33:06 +0000 (14:33 +0200)]
Use the lckpwdf() again if prefix is not set
The implementation of prefix option dropped the use of lckpwdf().
However that is incorrect as other tools manipulating the shadow passwords
such as PAM use lckpwdf() and do not know anything about the
shadow's own locking mechanism.
This reverts the implementation to use lckpwdf() if prefix option
is not used.
Chris Lamb [Wed, 2 Jan 2019 18:06:16 +0000 (18:06 +0000)]
Make the sp_lstchg shadow field reproducible (re. #71)
From <https://github.com/shadow-maint/shadow/pull/71>:
```
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.
```
This updated PR adds some missing calls to gettime (). This was originally
filed by Johannes Schauer in Debian as #917773 [2].
Tomas Mraz [Tue, 18 Dec 2018 15:32:13 +0000 (16:32 +0100)]
usermod: Guard against unsafe change of ownership of home directory content
In case the home directory is not a real home directory
(owned by the user) but things like / or /var or similar,
it is unsafe to change ownership of home directory content.
The test checks whether the home directory is owned by the
user him/herself, if not no ownership modification of contents
is performed.
Tomas Mraz [Wed, 28 Nov 2018 13:57:16 +0000 (14:57 +0100)]
login.defs: Add LASTLOG_UID_MAX variable to limit lastlog to small uids.
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.
idmap: always seteuid to the owner of the namespace
simplify the condition for setting the euid of the process. Now it is
always set when we are running as root, the issue was introduced with
the commit 52c081b02c4ca4432330ee336a60f6f803431e63
Changelog: 2018-11-24 - seh - enforce that euid only gets set to ruid if
it currently == 0 (i.e. really was setuid-*root*).
Closes: https://github.com/genuinetools/img/issues/191 Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com> Signed-off-by: Serge Hallyn <shallyn@cisco.com>
Commit 1ecca8439d5 ("new[ug]idmap: not require CAP_SYS_ADMIN in the parent userNS")
does contain a wrong commit message, is lacking an explanation of the
issue, misses some simplifications and hardening features. This commit
tries to rectify this.
In (crazy) environment where all capabilities are dropped from the
capability bounding set apart from CAP_SET{G,U}ID setuid- and
fscaps-based new{g,u}idmap binaries behave differently when writing
complex mappings for an unprivileged user:
First file_ns_capable(file, ns, CAP_SYS_ADMIN) is hit. This calls into
cap_capable() and hits the loop
for (;;) {
/* Do we have the necessary capabilities? */
if (ns == cred->user_ns)
return cap_raised(cred->cap_effective, cap) ? 0 : -EPERM;
/*
* If we're already at a lower level than we're looking for,
* we're done searching.
*/
if (ns->level <= cred->user_ns->level)
return -EPERM;
/*
* The owner of the user namespace in the parent of the
* user namespace has all caps.
*/
if ((ns->parent == cred->user_ns) && uid_eq(ns->owner, cred->euid))
return 0;
/*
* If you have a capability in a parent user ns, then you have
* it over all children user namespaces as well.
*/
ns = ns->parent;
}
The first check fails and falls through to the end of the loop and
retrieves the parent user namespace and checks whether CAP_SYS_ADMIN is
available there which isn't.
The first file_ns_capable() check for CAP_SYS_ADMIN is passed since the
euid has not been changed:
if ((ns->parent == cred->user_ns) && uid_eq(ns->owner, cred->euid))
return 0;
Now new_idmap_permitted() is hit which calls ns_capable(ns->parent,
CAP_SET{G,U}ID). This check passes since CAP_SET{G,U}ID is available in
the parent user namespace.
Now file_ns_capable(file, ns->parent, CAP_SETUID) is hit and the
cap_capable() loop (see above) is entered again. This passes
since CAP_SET{G,U}ID is available in the parent user namespace. Now the
mapping can be written.
There is no need for this descrepancy between setuid and fscaps based
new{g,u}idmap binaries. The solution is to do a
seteuid() back to the unprivileged uid and PR_SET_KEEPCAPS to keep
CAP_SET{G,U}ID. The seteuid() will cause the
file_ns_capable(file, ns, CAP_SYS_ADMIN) check to pass and the
PR_SET_KEEPCAPS for CAP_SET{G,U}ID will cause the CAP_SET{G,U}ID to
pass.
Fixes: 1ecca8439d5 ("new[ug]idmap: not require CAP_SYS_ADMIN in the parent userNS") Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
newuidmap/newgidmap: install with file capabilities
do not install newuidmap/newgidmap as suid binaries. Running these
tools with the same euid as the owner of the user namespace to
configure requires only CAP_SETUID and CAP_SETGID instead of requiring
CAP_SYS_ADMIN when it is installed as a suid binary.
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
Jakub Hrozek [Wed, 12 Sep 2018 12:22:11 +0000 (14:22 +0200)]
Flush sssd caches in addition to nscd caches
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.
Vladimir Ivanov [Fri, 3 Aug 2018 01:44:16 +0000 (09:44 +0800)]
Log UID in nologin
Sometimes getlogin() may fail, e.g., in a chroot() environment or due to NSS
misconfiguration. Loggin UID allows for investigation and troubleshooting in
such situation.
Michael Vogt [Mon, 25 Jun 2018 14:00:17 +0000 (16:00 +0200)]
su.c: run pam_getenvlist() after setup_env
When "su -l" is used the behaviour is described as similar to
a direct login. However login.c is doing a setup_env(pw) and then a
pam_getenvlist() in this scenario. But su.c is doing it the other
way around. Which means that the value of PATH from /etc/environment
is overriden. I think this is a bug because:
The man-page claims that "-l": "provides an environment similar
to what the user would expect had the user logged in directly."
And login.c is using the PATH from /etc/environment.
This will fix:
https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/984390
A. Wilcox [Sun, 24 Jun 2018 05:13:12 +0000 (00:13 -0500)]
Support systems that only have utmpx
This allows shadow-utils to build on systems like Adélie, which have no
<utmp.h> header or `struct utmp`. We use a <utmpx.h>-based daemon,
utmps[1], which uses `struct utmpx` only.
Tested both `login` and `logoutd` with utmps and both work correctly.
Michael Vetter [Tue, 15 May 2018 15:25:52 +0000 (17:25 +0200)]
Create parent dirs for useradd -m
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.
akrosikam [Mon, 12 Mar 2018 07:39:16 +0000 (08:39 +0100)]
Complete translation to Norwegian bokmål
Translate remaining strings to Norwegian bokmål (nb). Also, cure previous translation of excessive anglicism and apply a more consistent use of actual Norwegian syntax.
Aleksa Sarai [Thu, 15 Feb 2018 12:49:40 +0000 (23:49 +1100)]
newgidmap: enforce setgroups=deny if self-mapping a group
This is necessary to match the kernel-side policy of "self-mapping in a
user namespace is fine, but you cannot drop groups" -- a policy that was
created in order to stop user namespaces from allowing trivial privilege
escalation by dropping supplementary groups that were "blacklisted" from
certain paths.
This is the simplest fix for the underlying issue, and effectively makes
it so that unless a user has a valid mapping set in /etc/subgid (which
only administrators can modify) -- and they are currently trying to use
that mapping -- then /proc/$pid/setgroups will be set to deny. This
workaround is only partial, because ideally it should be possible to set
an "allow_setgroups" or "deny_setgroups" flag in /etc/subgid to allow
administrators to further restrict newgidmap(1).
We also don't write anything in the "allow" case because "allow" is the
default, and users may have already written "deny" even if they
technically are allowed to use setgroups. And we don't write anything if
the setgroups policy is already "deny".
projects / shadow / log