Hello,
last year I set up a FreeIPA installation. It works very well!
I lately discovered a problem with /etc/subuid and /etc/subgid used by rootless Podman (may be also Docker) containers.
During setup we decided to start the UID range exactly at 100.000. We picked that for no real reason other than we wanted a round number... We thought it would make sense and din't give it a second though.
What we did not know at that time is: The /etc/subuid and /etc/subgid system used by rootless Podman (may be also Docker) containers also starts exactly with uid 100.000.
So now if we would add users to /etc/subuid and /etc/subgid those users would be allowed using UID/GID fro the FreeIPA range. This requires attention each time a user is added to /etc/subuid and /etc/subgid and therefore can lead to potential security issues. We use configuration management for setting up our systems but we would prefer if we could achieve a safe default.
We would like to fix this without reinstalling FreeIPA. We have already a number of hosts, users and certificates enrolled.
I am now looking for a way to move the FreeIPA UID range to a different area, e.g. 10.000 - 20.000.
We run 3 replicas connected to each other.
I found the ipa comands 'idrange-add' and 'idrange-del' and wonder if I could use those to 1. add a new range at 10.000 2. Update UIDs of existing users 3. remove the old range at 100.000.
I am a bit hesitant trying this without understanding what complications I could run in.
Do you have any suggestions?
Best Friedrich Schäuffelhut
On 2/3/21 6:18 PM, Friedrich Schäuffelhut wrote:
We would like to fix this without reinstalling FreeIPA. We have already a number of hosts, users and certificates enrolled.
I am now looking for a way to move the FreeIPA UID range to a different area, e.g. 10.000 - 20.000.
We run 3 replicas connected to each other.
I found the ipa comands 'idrange-add' and 'idrange-del' and wonder if I could use those to
- add a new range at 10.000
- Update UIDs of existing users
- remove the old range at 100.000.
If I understand correctly moving your IPA range may be problematic since you are actively using the uids. Do you have substantial podman usage? If not, move the podman ranges away. They are automatically allocated according to SUB_UID_MIN et al. (man adduser): change those vars and reassign ranges for the existing users. Personally, I find the 100000+uid*65536 default rule terrible since it gives you unreadable final numbers. My rule is to rebuild everything from scratch after adding a new user with:
while IFS=":" read a b c x; do [ $c -eq 0 ] && c=1;echo "$a:$[100000*c]:65536";done </etc/passwd >/etc/subuid while IFS=":" read a b c x; do [ $c -eq 0 ] && c=1;echo "$a:$[100000*c]:65536";done </etc/group >/etc/subgid
which gives me 400015 for subuser 15 of user 4. (note that root=0 is problematic and I collapse it into bin=1, both starting at 100000)
Regards.
On 2/3/21 9:18 AM, Friedrich Schäuffelhut wrote:
I am a bit hesitant trying this without understanding what complications I could run in.
Other than the need to "chown" all the home directories, it should be ok. sssd caches the ids, but it should pick up the new ones at login and I can't think of anywhere else that would store them.
On 2/3/21 12:27 PM, Samuel Sieb wrote:
On 2/3/21 9:18 AM, Friedrich Schäuffelhut wrote:
I am a bit hesitant trying this without understanding what complications I could run in.
Other than the need to "chown" all the home directories, it should be ok. sssd caches the ids, but it should pick up the new ones at login and I can't think of anywhere else that would store them.
I see Roberto's answer now and I realized I should have added that if you could change the podman uids, that would be the much better option. Somehow from your email I was thinking that wasn't possible.
On 2/3/21 6:18 PM, Friedrich Schäuffelhut wrote:
If I understand correctly moving your IPA range may be problematic since you are actively using the uids.
Moving user ids is not a concern. We are in a transition phase where most users still have a local account and use local uids. We are planning to roll out an os update for our desktops soon and with that we are goint to switch to sssd/LDAP based users.
Do you have substantial podman usage? If not, move the podman ranges away. They are automatically allocated according to SUB_UID_MIN et al. (man adduser): change those vars and reassign ranges for the existing users.
We considered this. We want to avoid future accidental clashes. Now it would still be possible to fix it.
Personally, I find the 100000+uid*65536 default rule terrible since it gives you unreadable final numbers.
I see it the same way.
My rule is to rebuild everything from scratch after adding a new user with:
while IFS=":" read a b c x; do [ $c -eq 0 ] && c=1;echo "$a:$[100000*c]:65536";done </etc/passwd >/etc/subuid while IFS=":" read a b c x; do [ $c -eq 0 ] && c=1;echo "$a:$[100000*c]:65536";done </etc/group >/etc/subgid
which gives me 400015 for subuser 15 of user 4. (note that root=0 is problematic and I collapse it into bin=1, both starting at 100000)
We did discuss these options internally.
We understand the administrative tasks that must happen on client systems, when changing UIDs in FreeIPA e.g. fixing file owner ships (not a problem for us).
We also use configuration management for setting up subuid/subguid files.
We really want to get rid of that UID overlap between our FreeIPA install and subuid/subguid to avoid future confusion/accidents and unexpected behavior.
What we really would like to understand is, if it is possible to move the UID/GUID range in FreeIPA and how to do it.
Regards Friedrich Schäuffelhut
On Wed, Feb 03, 2021 at 08:41:56PM -0000, Friedrich Schäuffelhut wrote:
On 2/3/21 6:18 PM, Friedrich Schäuffelhut wrote:
If I understand correctly moving your IPA range may be problematic since you are actively using the uids.
Moving user ids is not a concern. We are in a transition phase where most users still have a local account and use local uids. We are planning to roll out an os update for our desktops soon and with that we are goint to switch to sssd/LDAP based users.
You should probably be aware that subuid/subgid isn't populated for sssd/ldap accounts, so youll have to manage those manually.
I think there are some plans to get nss to talk to sssd to pull it from a network source, but it isn't implemented.
https://github.com/shadow-maint/shadow/issues/154
On Wed, Feb 03, 2021 at 08:41:56PM -0000, Friedrich Schäuffelhut wrote:
You should probably be aware that subuid/subgid isn't populated for sssd/ldap accounts, so youll have to manage those manually.
Thank you, I do understand that and I know how to manage it.
I think there are some plans to get nss to talk to sssd to pull it from a network source, but it isn't implemented.
I am aware of that ticket and I am looking forward to a possible integration.
Regards Friedrich Schäuffelhut
Roberto Ragusa wrote:
while IFS=":" read a b c x; do [ $c -eq 0 ] && c=1;echo "$a:$[100000*c]:65536";done </etc/passwd >/etc/subuid
Nice example. I enjoy reading a useful one-liner here.
The "$[]" caught my eye, as it has come up a few times on the bash list. For anyone unfamiliar, it's an older, deprecated form of arithmetic expansion, i.e.: "$(())".
As bash maintainer Chet Ramey said of "$[]" in one of the more recent threads¹:
I probably won't remove it, but nobody should use it in new code.
Old habits... I'm sure. ;)
¹ https://lists.gnu.org/archive/html/bug-bash/2020-07/msg00036.html
-
Friedrich Schäuffelhut -
Jonathan Billings -
Roberto Ragusa -
Samuel Sieb -
Todd Zullinger