[baseimage]: specify gid for redis group.#7249
[baseimage]: specify gid for redis group.#7249renukamanavalan merged 4 commits intosonic-net:masterfrom
Conversation
By explicilty specifying something other than 1000, it leaves behind 1000 for grab, which is
duly taken by admin group, as required.
BTW, TACACS RW users use, 1000 as gid.
Test result:
admin@str-s6000-acs-9:~$ cat /etc/group | grep -e "admin\|redis"
sudo:x:27:admin,user_rw
docker:x:999:admin,user_rw
redis:x:1001:admin --- takes 1001
admin:x:1000:
admin@str-s6000-acs-9:~$
admin@str-s6000-acs-9:~$ ls -l /home
total 4
drwxr-xr-x 2 admin admin 66 Apr 7 14:53 admin
drwxr-xr-x 2 user_rw admin 4096 Apr 7 15:47 user_rw -- RW user get admin group
renukamanavalan
requested review from
abdosi,
lguohan,
prsunny,
qiluo-msft and
tahmed-dev
lguohan
changed the title
build_debian.sh
Outdated
|
|
||
| ## Create redis group | ||
| sudo LANG=C chroot $FILESYSTEM_ROOT groupadd -f redis | ||
| sudo LANG=C chroot $FILESYSTEM_ROOT groupadd -f -g 1001 redis |
There was a problem hiding this comment.
1001 [](start = 51, length = 4)
I think the motivation is not to fix the gid for redis, but fix the gid for admin to 1000.
So suggest
- create a group with gid 1000 and name
$USERNAME - create a group
rediswithout specifying gid - create user
$USERNAMEwith-g 1000and also in the groupssudo,docker,redis#Closed
There was a problem hiding this comment.
Agree, we need not fix gid for redis. But we need to fix gid for "admin" group.
At the same time, it does not limit/restrict anything by explicitly specifying gid for redis.
This fix is nearly a no-op for all purposes as all that is required is a redis group and we continue to have it as before.
There was a problem hiding this comment.
can we pin down the admin group id to 1000 more directly?
There was a problem hiding this comment.
We could. Just a groupadd. Not sure, about any side effects. Just trying to make the change close to no-op. This change is ~= NO-OP
There was a problem hiding this comment.
Hold on....There could be something simpler
There was a problem hiding this comment.
Done. Just shifted order of creation.
build_debian.sh
Outdated
| # Ensure admin gid 1000 is available | ||
| gid_1000=$(sudo LANG=C grep -e ":1000:" $FILESYSTEM_ROOT/etc/group) | ||
| if [ -n "${gid_1000}" ]; then | ||
| if [ "${gid_1000}" != "admin:x:1000:" ]; then |
There was a problem hiding this comment.
admin [](start = 27, length = 5)
admin is customizable. Use $USERNAME instead.
I guess you can just id -g $USERNAME #Closed
There was a problem hiding this comment.
Good catch! Thank you!
Problem: Default groupadd for redis, takes 1000 by default. This forces, subsequently created admin group to get 1001. As all TACACS users are created with 1000 as their gid, they end up in redis group. Fix: Create redis group *after* admin group is created Add a check that admin group id is 1000
qiluo-msft
left a comment
qiluo-msft
left a comment
There was a problem hiding this comment.
Looks great, thanks!
Problem: Default groupadd for redis, takes 1000 by default. This forces, subsequently created admin group to get 1001. As all TACACS users are created with 1000 as their gid, they end up in redis group. Fix: Create redis group *after* admin group is created Add a check that admin group id is 1000
Problem: Default groupadd for redis, takes 1000 by default. This forces, subsequently created admin group to get 1001. As all TACACS users are created with 1000 as their gid, they end up in redis group. Fix: Create redis group *after* admin group is created Add a check that admin group id is 1000
Problem: Default groupadd for redis, takes 1000 by default. This forces, subsequently created admin group to get 1001. As all TACACS users are created with 1000 as their gid, they end up in redis group. Fix: Create redis group *after* admin group is created Add a check that admin group id is 1000
Why I did it
Default groupadd for redis, takes 1000 by default. This forces, subsequently created admin group to get 1001.
As all TACACS users are created with 1000 as their gid, they end up in redis group.
How I did it
Switched the order of group creation. Move redis group creation command after the command that creates admin group.
How to verify it
Check /etc/group & group of RW users via TACACS
Which release branch to backport (provide reason below if selected)
Description for the changelog
A picture of a cute animal (not mandatory but encouraged)