Currently this has three functions: one which returns the
list of subuid ranges for a user, one returning the subgids,
and one which frees the ranges lists.
I might be mistaken about what -disable-man means; some of
the code suggests it means just don't re-generate them, but
not totally ignore them. But that doesn't seem to really work,
so let's just ignore man/ when -disable-man.
Remove --disable-shared. I'm not sure why it was there, but it stems
from long, long ago, and I suspect it comes from some ancient
toolchain bug.
Create a tests/run_some, a shorter version of run_all. I'll
slowly add tests to this as I verify they work, then I can
work on fixing the once which don't.
Also, don't touch man/ if not -enable-man.
Changelog:
Apr 22: change the subid list api as recomended by Dan Walsh.
Apr 23: implement get_subid_owner
Apr 24: implement range add/release
Apr 25: finish tests and rebase
May 10: make @owner const
According to crypt(5), MD5 and DES should not be used for new
hashes. Also the default number of SHA rounds chosen by libc is orders
of magnitude too low for modern hardware. Let's warn the users about
weak choices.
Tomas Mraz [Mon, 20 Jan 2020 12:58:07 +0000 (13:58 +0100)]
Do not mistake a regular user process for a namespaced one
In case there is a regular user with a process running on a system
with uid falling into a namespaced uid range of another user.
The user with the colliding namespaced uid range will not be
allowed to be deleted without forcing the action with -f.
The user_busy() is adjusted to check whether the suspected process
is really a namespaced process in a different namespace.
updated Dutch translation for shadow version 4.8 (pot file from 2019-12-01).
I updated the translation for Debian
and on request of the Debian package maintainer Bálint Réczey I am creating this pull request
Tomas Mraz [Thu, 16 Jan 2020 11:55:30 +0000 (12:55 +0100)]
Make the check for non-executable shell only a warning.
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.
Duncan Overbruck [Sat, 11 Jan 2020 21:19:37 +0000 (22:19 +0100)]
add new HOME_MODE login.defs(5) option
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.
Duncan Overbruck [Sat, 11 Jan 2020 21:19:37 +0000 (22:19 +0100)]
add new HOME_MODE login.defs(5) option
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.
`make` runs each line in a shell and bails out on error,
however, the shell is not started with `-e`, so commands in
`for` loops can fail without the error actually causing
`make` to bail out with a failure status.
For instance, the following make snippet will end
successfully, printing 'SUCCESS', despite the first `chmod`
failing:
all:
touch a b
for i in a-missing-file a b; do \
chmod 666 $$i; \
done
@echo SUCCESS
To prevent wrong paths in install scripts from remaining
unnoticed, let's activate `set -e` in the `for` loop
subshells.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
Michael Weiser [Tue, 17 Dec 2019 20:13:07 +0000 (21:13 +0100)]
man: Don't suggest making groupmems user-writeable
Suggesting mode 2770 is dangerous because it makes the binary writeable
by all members of the owning group which is supposed to be normal
end-users. Suggest 2710 instead as is usual for s[ug]id binaries,
allowing execution but neither reading nor writing.
Signed-off-by: Michael Weiser <michael.weiser@gmx.de>
Dave Reisner [Mon, 16 Dec 2019 19:11:23 +0000 (14:11 -0500)]
Don't auto-enable ACCT_TOOLS_SETUID if PAM is detected
Here's a sad story:
* 70971457 is merged into shadow, allowing newgidmap/newuidmap to be
installed with file caps rather than setuid.
* https://bugs.archlinux.org/task/63248 is filed to take advantage of
this.
* The arch maintainer of the 'shadow' package notices that this doesn't
work, and submits a pull request to fix this in shadow.
* edf7547ad5 is merged, fixing the post install hooks.
The problem here is that distros have been building shadow with PAM for
O(years), but the install hooks have silently failed due to the
combination of the directory mismatch (suidubins vs suidsbins) and later
success with setuid'ing newgidmap/newuidmap.
With the install hooks fixed, those of us (Arch[1] and Gentoo[2] so far)
who never built shadow explicitly with --enable-account-tools-setuid are
now getting setuid account tools, and don't have PAM configuration
suitable for use with setuid account management tools.
It's entirely unclear to me why you'd want this, but I assume there's
some reason out there for it existing. Regardless, setuid binaries are
dangerous and shouldn't be enabled by default without good reason.
See https://github.com/shadow-maint/shadow/issues/196
Some distros still care about `/bin` vs `/usr/bin`. This commit makes
it so all binaries are always installed to `/bin`/`/sbin`. The only way to
restore the previous behaviour of installing some binaries to
`/usr/bin`/`/usr/sbin` is to revert the patch.
projects / thirdparty / shadow.git / log
