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.
Thanks!
Signed-off-by: Hank Leininger <hlein@korelogic.com>
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
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.
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.
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.
Signed-off-by: Duncan Eastoe <deastoe@Brocade.com>
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
When referring to USERGROUPS_ENAB, the German mentions /etc/default/useradd
when it should be /etc/login.defs (like the original English does).
Reported-by: Stefan Kiesler <heavymetal@gmx.de>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
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>
We're losing the svn history (which we could probably keep if we tried
hard enough) but don't consider that worthwhile.
Note these tests are destructive, so run them only in a throwaway
environment like a chroot, container, or vm.
The tests/run.all script should be the one which launches all the tests.
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
This built-in check is simpler than the previous method and, most
importantly, works when cross-compiling.
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
Currently shadow fails to build from source and is flagged as
out-of-date. This is due to a usage of PATH_MAX, which is not defined
on GNU/Hurd. The attached patch solves this problem by allocating a
fixed number of 32 bytes for the string proc_dir_name in files
src/procuidmap.c and src/procgidmap.c. (In fact only 18 bytes are
needed)
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
Users may otherwise be confused and think that because the kernel
does not restrict uid mappings to the root user (within his
current uid mappings), newuidmap will ignore /etc/subuid for the
root user. It will not.
Reported-by: Philippe Grégoire <gregoirep@hotmail.com>
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
Acked-by: "Eric W. Biederman" <ebiederm@xmission.com>
The number of ranges should be the ceiling of the number of arguments divided
by three.
Without this fix newuidmap and newgidmap always report and error and fail,
which is very much not what we want.
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
* man/login.defs.d/SUB_GID_COUNT.xml: Document newusers behavior
when the user already have subordinate group IDs.
* man/login.defs.d/SUB_UID_COUNT.xml: Likewise.
* man/login.defs.d/SUB_GID_COUNT.xml: Fix typo (MAX<->MIN).
* man/login.defs.d/SUB_UID_COUNT.xml: Likewise.
* 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().
