$restrict_user and high system UIDs

The question is in regard to the possibility to restrict node access to users actually running a job on a particular compute node with $restrict_user, $restrict_user_maxsysid and $restrict_user_exceptions.
(Reader: Admin Guide v13 §3.6.6 p 64).

First comment is that I love the feature. It makes a lot of sense.

Second comment is that I would like slightly more flexibility. My problem is that while we have “real user” UIDs starting at some level (200).
However, on our new CentOS72 system, there are also a number of system users with very high UIDs, such as systemd-network (UID=999) - and nfsnobody (UID=65534) [no, we do not allow nfsnobody - it is just an example].

Basically, I would go for a setup like (added to mom_priv/config):

$restrict_user on
$restrict_user_maxsysid 200
$restrict_user_exceptions

However, pbs then happily kills all daemons running on UID>200.

So, I could move all the user UIDs to some sufficiently high number, and then hope that no daemon will install in that new range. This would mean changing all UIDs accross all our machines and file servers, so it is not really a feasible solution for me.

Alternatively, I could identify all the high-UID “system” users in /etc/passwd, and explicitly name them under $restrict_user_exceptions. (This would need to be updated if a new service is then installed). This is the way I am considering to do it now, but the list may be long, and will need update if more daemons are added (so it is error prone).

As an alternative, I would suggest to define one (or more) “user ranges” (or alternatively sysid ranges), which may be killed (or not killed) rather than the present simple split into only one range for sysid (low numbers) and one for users (high numbers).

Before I add a request, I want to ask if anybody else have this need - or maybe a solution already exists.

Thanks,

/Bjarne

After digging a little, it may seem that the “right solution” for us is to move all UIDs (and GIDs) of “real users” up into the 1000+ range. (It just happens to be a lot of work, and rather complicated to do on a live production system).

Any and all comments are still welcome!

/Bjarne