lists.arthurdejong.org
RSS feed

ignoring uids above a given value

[Date Prev][Date Next] [Thread Prev][Thread Next]

ignoring uids above a given value



I'm wondering if any thought has been given to an nslcd option similar
to nss_min_uid but used to ignore uids/gids above a particular value.

The reason I ask is because I've hit a bit of a snag recently on Linux
systems using user namespaces which, if you're not familiar with the
mechanics there, generally use high value uids and gids ranges in the
parent namespace to remap, in chunks, to ranges in the child
namespace.  The problem I'm facing is that these high value uids
outside the user namespace (where nslcd is running) represent a big
range of ids that will (should) never exist in my directory.  (They
don't even exist outside the user namespace as actual entries in the
password or group databases either.)  That doesn't mean there won't be
objects in the filesystem that are owned by those ids, and there will
certainly be processes running as those uids ... they're just not
mapped to any named user outside of the user namespace.  Yet, when
some agressive application comes along and starts scanning the process
tables (or winding its way through /proc) or digging through the
filesystem, this in turn ends up generating quite a bit of ldap
activity none of which ever has any results, but is fairly expensive
server-side.  I'd like to short circuit that if I can.

Perhaps a nss_max_uid directive is too simplistic and there's a more
elegant way to mask uid/gid ranges that have been delegated for
remapping ... but as far as I know the subordinate id system in Linux
isn't known to any libc functions, as it's really just a /proc based
control interface with some convenience applications bundled as part
of the shadow suite.  Anyway, I'm currious what others think.  I
haven't really thought entirely through what all the ramifications
could be to something like a nss_max_uid directive, but if there's
nothing too obviously horrible with the idea I imagine it might not be
too tricky to implement.

-- 
Jamie Heilman                     http://audible.transient.net/~jamie/