Hi Mike,

From user.eclass:

146         if [[ ${euid} -gt 0 ]] ; then
147             if [[ -n $(egetent passwd ${euid}) ]] ; then
148                 [[ -n ${force_uid} ]] && die "${FUNCNAME}: UID ${euid} already taken"
149                 euid="next"
150             fi
151         else
152             eerror "Userid given but is not greater than 0 !"
153             die "${euid} is not a valid UID"
154         fi

Similar for egid.

This is the discrepency of >=0 (acct-user and acct-group) vs >0 (user) I was referring.  So yes, I can set it, but the underlying enewuser and enewgroup calls is going to kick out as per above.

Yes, I could use something like uid=1 (bin) and gid=1 (bin) which I'm reasonably sure use comes from baselayout and is thus almost guaranteed to conflict always, but the *intention* of that's unclear.  I'd rather (and I'm happy to write the patches, just don't want to waste my time doing so if it's of no interest to anyone else) have a way to explicitly state "I really don't care about this uid or gid value".  Also, should it be required to be set to eg -1 to indicate this, or is the variable not being set a good enough indication?  I'm included to require -1 else a simple typo could result in accidental dynamic allocation.

Regarding your $RANDOM idea ... that is rather crazy, and will work, however, I suspect you should make that % 499 ... saw an email earlier about the IDs should be <500 since 500 to 999 is reserved for dynamic allocation.

I currently have at least four dynamically allocated groups on the machine I'm typing this on:

tcpdump:x:999:
mrtg:x:998:
rrd:x:997:
ulsreport:x:996:

I like the idea of it being allocated from 999 downwards, and I really think dynamic allocation makes sense for many packages.  I do support the idea of predictable IDs, for packages which can trivially use shared storage (eg, mail).  For other packages (eg, webrtc2sip which I'm working with currently) it seriously doesn't matter as it'll never write to disk (other than the log files ...). Heck, even if it could, sharing that state wouldn't make much sense either.  Even something like asterisk being predictable makes sense, since /var/spool/asterisk/monitor (and a few others, as we currently are) could be shared between multiple hosts.

Kind Regards,

On Thu, Aug 1, 2019 at 3:04 PM Jaco Kroon <jaco@uls.co.za> wrote:

Hi,

Looking at the new eclasses for acct-user and acct-group.

These enforce that a group and user id should be set.

This is not a requirement for enewuser nor enewgroup.

The new eclasses require you to set a fixed id, but they do not
enforce that the id is available by default. If the id is taken
already, it will allocate a new one.

User/group 0 is pretty much guaranteed to always exist, so you could
set ACCT_{GROUP,USER}_ID=0 to trigger the desired behavior.

If you're feeling crazy, this will get you a random assignment between
1 and 999, with the same fallback logic.

ACCT_GROUP_ID=$(( RANDOM % 998 + 1 ))