lima-vm
issue 2117: disallow admin username
disallow admin username; use fallback username. Related issue: https://github.com/lima-vm/lima/issues/2117
This is unfortunately not going to be as simple as changing the regex. The changed default setting must be made conditional on the version of Lima that creates the VM, otherwise you are going to break existing instances. #2107 introduces code that will make this possible.
I'm also wondering if we special-case admin (purely for the benefit of Ubuntu), if we should disallow other well-known Linux user and group names as well? Random list: root, bin, adm, daemon, games, postmaster, guest, nobody, ntp, but there are plenty more. And then there are lots of common group names too.
This is unfortunately not going to be as simple as changing the regex. The changed default setting must be made conditional on the version of Lima that creates the VM, otherwise you are going to break existing instances. #2107 introduces code that will make this possible.
I'm also wondering if we special-case
admin(purely for the benefit of Ubuntu), if we should disallow other well-known Linux user and group names as well? Random list:root,bin,adm,daemon,games,postmaster,guest,nobody,ntp, but there are plenty more. And then there are lots of common group names too.
Hi @jandubois , Thank you for your comment. assume that the current user is admin, then they can not have any instance running. For other Linux user and group, we can add up if there is an issue.
assume that the current user is admin, then they can not have any instance running.
This is not correct; only Ubuntu has a predefined admin group that conflicts; other templates run fine with an admin user.
assume that the current user is admin, then they can not have any instance running.
This is not correct; only Ubuntu has a predefined
admingroup that conflicts; other templates run fine with anadminuser.
Thank you, I understand now.
Hi @bo17age,
My thoughts around how this should be handled have evolved since you originally opened this PR. I thought you had abandoned it, which is why I didn't write them down earlier.
I think we should make the username configurable in lima.yaml:
user:
name: null
And then FillDefaults should fill in the default user name according to our rules (set user.name to "lima" if the local user name doesn't look like a valid Linux user name). This is also where the check for the admin user would move.
If the lima.yaml already specifies a user name, then we accept it without further validation (so the user could force it to be admin because that would still work for non-Ubuntu images).
All other locations should use y.User.Name instead of calling osutil.LimaUser().
The user could then also add it to their override.yaml and always use lima or whatever as the user name and not use the host user name ever.
I want to use a nested user.name instead of a top-level username because we may want to allow the user to override other settings in the future, like the gid/uid. This will allow us to disable more Lima-specific configurations beyond what cloud-init does by default. @afbjorklund knows more about these requirements.
Note that I have not yet verified if all the locations that currently call osutil.LimaUser have easy access to the limayaml structure, so maybe this requires some additional refactoring.
Sorry for moving the goal-post at this late stage, but let me know if you are up for modifying your PR along those lines.
Alternatively I could review this PR as is, and then make the changes I described above in a follow-up PR myself.
Hi @jandubois , Thank you for your suggestion. Yes, I'm willing to make the change and will start soon.
Yes, I'm willing to make the change and will start soon.
Hi @bo17age,
Did you get a chance to work on this?
We are planning for a Lima 1.0 release later this month, or very early in November, and there will be some changes in default behaviour already. So it would be good to make the change for the admin user name at the same time.
Let me know if you think you cannot finish it by some time next week, and I can give it a try myself!
Let me know if you think you cannot finish it by some time next week, and I can give it a try myself!
Sorry, I meant: let me know if you can finish it yourself by next week, or if that is going to be too tight for you. In that case I can try to do it myself.
In that case I can try to do it myself.
I've implemented it in #2827. Turned out to be a bit more complex than originally anticipated.
Thank you @bo17age for spending the effort on the original PR, it is appreciated, even though it will not be merged.