| 1 |
Hi Mike, |
| 2 |
|
| 3 |
From user.eclass: |
| 4 |
|
| 5 |
146 if [[ ${euid} -gt 0 ]] ; then |
| 6 |
147 if [[ -n $(egetent passwd ${euid}) ]] ; then |
| 7 |
148 [[ -n ${force_uid} ]] && die "${FUNCNAME}: UID |
| 8 |
${euid} already taken" |
| 9 |
149 euid="next" |
| 10 |
150 fi |
| 11 |
151 else |
| 12 |
152 eerror "Userid given but is not greater than 0 !" |
| 13 |
153 die "${euid} is not a valid UID" |
| 14 |
154 fi |
| 15 |
|
| 16 |
Similar for egid. |
| 17 |
|
| 18 |
This is the discrepency of >=0 (acct-user and acct-group) vs >0 (user) I |
| 19 |
was referring. So yes, I can set it, but the underlying enewuser and |
| 20 |
enewgroup calls is going to kick out as per above. |
| 21 |
|
| 22 |
Yes, I could use something like uid=1 (bin) and gid=1 (bin) which I'm |
| 23 |
reasonably sure use comes from baselayout and is thus almost guaranteed |
| 24 |
to conflict always, but the *intention* of that's unclear. I'd rather |
| 25 |
(and I'm happy to write the patches, just don't want to waste my time |
| 26 |
doing so if it's of no interest to anyone else) have a way to explicitly |
| 27 |
state "I really don't care about this uid or gid value". Also, should |
| 28 |
it be required to be set to eg -1 to indicate this, or is the variable |
| 29 |
not being set a good enough indication? I'm included to require -1 else |
| 30 |
a simple typo could result in accidental dynamic allocation. |
| 31 |
|
| 32 |
Regarding your $RANDOM idea ... that is rather crazy, and will work, |
| 33 |
however, I suspect you should make that % 499 ... saw an email earlier |
| 34 |
about the IDs should be <500 since 500 to 999 is reserved for dynamic |
| 35 |
allocation. |
| 36 |
|
| 37 |
I currently have at least four dynamically allocated groups on the |
| 38 |
machine I'm typing this on: |
| 39 |
|
| 40 |
tcpdump:x:999: |
| 41 |
mrtg:x:998: |
| 42 |
rrd:x:997: |
| 43 |
ulsreport:x:996: |
| 44 |
|
| 45 |
I like the idea of it being allocated from 999 downwards, and I really |
| 46 |
think dynamic allocation makes sense for many packages. I do support |
| 47 |
the idea of predictable IDs, for packages which can trivially use shared |
| 48 |
storage (eg, mail). For other packages (eg, webrtc2sip which I'm |
| 49 |
working with currently) it seriously doesn't matter as it'll never write |
| 50 |
to disk (other than the log files ...). Heck, even if it could, sharing |
| 51 |
that state wouldn't make much sense either. Even something like |
| 52 |
asterisk being predictable makes sense, since |
| 53 |
/var/spool/asterisk/monitor (and a few others, as we currently are) |
| 54 |
could be shared between multiple hosts. |
| 55 |
|
| 56 |
Kind Regards, |
| 57 |
|
| 58 |
Jaco Kroon |
| 59 |
|
| 60 |
On 2019/08/01 22:01, Mike Gilbert wrote: |
| 61 |
|
| 62 |
> On Thu, Aug 1, 2019 at 3:04 PM Jaco Kroon <jaco@××××××.za> wrote: |
| 63 |
>> Hi, |
| 64 |
>> |
| 65 |
>> Looking at the new eclasses for acct-user and acct-group. |
| 66 |
>> |
| 67 |
>> These enforce that a group and user id should be set. |
| 68 |
>> |
| 69 |
>> This is not a requirement for enewuser nor enewgroup. |
| 70 |
> The new eclasses require you to set a fixed id, but they do not |
| 71 |
> enforce that the id is available by default. If the id is taken |
| 72 |
> already, it will allocate a new one. |
| 73 |
> |
| 74 |
> User/group 0 is pretty much guaranteed to always exist, so you could |
| 75 |
> set ACCT_{GROUP,USER}_ID=0 to trigger the desired behavior. |
| 76 |
> |
| 77 |
> If you're feeling crazy, this will get you a random assignment between |
| 78 |
> 1 and 999, with the same fallback logic. |
| 79 |
> |
| 80 |
> ACCT_GROUP_ID=$(( RANDOM % 998 + 1 )) |
| 81 |
> |
Archives