Commit Graph

8 Commits

Author SHA1 Message Date
Serge Hallyn
2b22a6909d libsubid: don't print error messages on stderr by default
Closes #325

Add a new subid_init() function which can be used to specify the
stream on which error messages should be printed.  (If you want to
get fancy you can redirect that to memory :)  If subid_init() is
not called, use stderr.  If NULL is passed, then /dev/null will
be used.

This patch also fixes up the 'Prog', which previously had to be
defined by any program linking against libsubid.  Now, by default
in libsubid it will show (subid).  Once subid_init() is called,
it will use the first variable passed to subid_init().

Signed-off-by: Serge Hallyn <serge@hallyn.com>
2021-05-15 12:38:55 -05:00
Martijn de Gouw
c464ec5570 newuidmap,newgidmap: Relax gid checking to allow running under alternative group ID
Signed-off-by: Martijn de Gouw <martijn.de.gouw@prodrive-technologies.com>
2021-02-08 13:32:18 +01:00
Serge Hallyn
b03df41906 remove unused variables
parent, user_id, and group_id are unused.

Signed-off-by: Serge Hallyn <shallyn@cisco.com>
2019-10-12 20:03:32 -05:00
Giuseppe Scrivano
1ecca8439d
new[ug]idmap: not require CAP_SYS_ADMIN in the parent userNS
if the euid!=owner of the userns, the kernel returns EPERM when trying
to write the uidmap and there is no CAP_SYS_ADMIN in the parent
namespace.

Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
2018-10-22 16:57:50 +02:00
Tobias Stoeckmann
a84b0cafdd Fixed typos in new{g,u}idmap tools.
Fixed small typos in manual pages and code comments.

Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>
2016-07-02 16:39:18 +02:00
Hank Leininger
884895ae25 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.

Thanks!

Signed-off-by: Hank Leininger <hlein@korelogic.com>
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
2015-04-06 08:23:36 -05:00
Serge Hallyn
4911773b77 From: Svante Signell <svante.signell@gmail.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>
2014-06-26 16:48:56 -05:00
Eric W. Biederman
673c2a6f9a newuidmap,newgidmap: New suid helpers for using subordinate uids and gids
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
2013-08-05 10:08:46 -05:00