-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[baseimage]: specify gid for redis group. #7249
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
build_debian.sh
Outdated
@@ -245,7 +245,7 @@ sudo cp files/docker/docker.service.conf $_ | |||
sudo sed -i '/After=/s/$/ containerd.service/' $FILESYSTEM_ROOT/lib/systemd/system/docker.service | |||
|
|||
## 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
redis
without specifying gid - create user
$USERNAME
with-g 1000
and also in the groupssudo,docker,redis
#Closed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can we pin down the admin group id to 1000 more directly?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hold on....There could be something simpler
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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)