On 1/14/22 12:15 PM, Daniel Gerber wrote:
2022-01-14, Sean Anderson:
It's stack garbage. Try
diff --git i/sys-utils/unshare.c w/sys-utils/unshare.c
index 3cdd90329..5ac7af3de 100644
--- i/sys-utils/unshare.c
+++ w/sys-utils/unshare.c
@@ -385,10 +385,10 @@ struct map_range {
*/
static int uint_to_id(const char *name, size_t sz)
{
- char buf[UID_BUFSIZ];
+ char buf[UID_BUFSIZ] = {0};
- mem2strcpy(buf, name, sz, sizeof(buf));
- return strtoul_or_err(name, _("could not parse ID"));
+ memcpy(buf, name, min(sz, sizeof(buf) - 1));
+ return strtoul_or_err(buf, _("could not parse ID"));
}
/**
That works, thanks.
OK, I will submit it.
Also, I would suggest adopting the same argument order as in /proc/<pid>/uid_map and newuidmap -- inner,outer,count.
I think this is a rather silly order. Since this is a mapping, the "natural" order is
outer -> inner
and only from the new namespace's PoV is it
inner -> outer
It certainly helped me remember things once I reversed the order...
All right, this may make some sense to me now. To the user discovering these tools though (me yesterday) the worst is missing one "standard" notation...
Yeah, I'm not terribly happy about it. That's why I added an "auto" feature, so you wouldn't have to remember the order.
This doc string has it reversed:
As noted above, this is intended.
* struct map_range - A range of IDs to map
* @outer: First ID inside the namespace
* @inner: First ID outside the namespace
I mean "@outer: First ID inside ..." surely is a typo, isn't it?
Yes, you're right.
--Sean
