Automatic login as dietpi

[FredericGuilbault]

Status: WIP

Reference: https://github.com/MichaIng/DietPi/issues/XXXX

Commit list/description:

Add an other option for automatic login option to log as dietpi user instead of root.

In fact, best solution would be to log as UID 1000 What ever de the name is. but agetty does not support it .

[MichaIng]

@FredericGuilbault
Many thanks for the idea. What do you think about simply allowing to freely enter/select the username, when choosing one of the autologin options?

Or we add another layer to the menu, e.g.:

Autologin user : [dietpi] Select a login user for autostart options that skip logins
Autostart option: [Desktop] Select an option/program to automatically start on boot

• Hmm no, I think it's easier to have a second prompt after an autologin option has been chosen.

We can scrape /etc/passwd for existing login usernames (those with /bin/*sh as login shell).

This allows to start e.g. Chromium Kiosk mode and the games as non-root as well, which should be preferred anyway.
And I aim to make dietpi itself a system user by times, instead allow to create a custom user on first login.

[FredericGuilbault]

For my usecase, it's gonna be all automated. I don't need the dialog. So if we implement a dialog we must implement a dietpi.txt variable for it.

It's a linux standard that no Users with UID < 1000 should boot a graphical interface. Or even a shell in normal operations (exept root).

Querying /etc/passwd would be a good approch if we keep only result bigger then UID 999
At the same time. it's hard coded by PREP_SYSTEM_FOR_DIETPI.sh that the uid 1000 will be named dietpi and there will be no other UID over 1000.

But it's best practice to avoid blindly relying on hardcoded stuff.

using /etc/passwd is a good idea. I think I would go for asking /etc/passwd for the name of uid 1000. and setting this in the .service file.

--
On an other topic. In a prefect world ,This service file should not be dinamicaly created and destroyed. But enabled and disabled. Im ok with the way it is ATM. but I would keep in mind that one day. it might be a permanent .service file.

[FredericGuilbault]

id -un 1000 seem to do the job too

[MichaIng]

@FredericGuilbault

For my usecase, it's gonna be all automated. I don't need the dialog. So if we implement a dialog we must implement a dietpi.txt variable for it.

Agree!

Querying /etc/passwd would be a good approch if we keep only result bigger then UID 999
At the same time. it's hard coded by PREP_SYSTEM_FOR_DIETPI.sh that the uid 1000 will be named dietpi and there will be no other UID over 1000.

Jep the DietPi-PREP behaviour of course would be changed then, to simply create dietpi as system user via useradd -r dietpi .... It will most likely get ID 999 then (if free), however assured one <1000.

id -un 1000

Great find, didn't know that! That's much easier. However just theoretically it is possible to create a login user without login shell, e.g. useradd test -s $(command -v nologin) (or -s /bin/false) will create a user with >=1000 ID but it cannot login. Unlikely someone does this, but to be failsafe we could check /etc/passwd or getent passwd for a valid login shell as well. But perhaps a bid overkill. I would just assure that one falls back to a login mask. Otherwise SSH or serial console would be required to recover the ability to login on tty1.

---

On an other topic. In a prefect world ,This service file should not be dinamicaly created and destroyed. But enabled and disabled. Im ok with the way it is ATM. but I would keep in mind that one day. it might be a permanent .service file.

The service ([email protected]) is permanent. What we do to allow auto login is create a drop-in config that

• Check out: systemctl cat getty@tty1
  • ExecStart=-/sbin/agetty -o '-p -- \\u' --noclear %I $TERM spawns the login prompt on TTY1.
• What we create for autologin autostart options:

cat /etc/systemd/system/[email protected]/dietpi-autologin.conf
[Service]
ExecStart=
ExecStart=-/sbin/agetty --autologin root %I $TERM

• It resets the default ExecStart of this service and adds the command with autologin as root.
• This is where we then need to add the chosen user instead.

---

Okay do you agree with this final solution:

• Add a G_WHIP_MENU here: https://github.com/MichaIng/DietPi/blob/dev/dietpi/dietpi-autostart#L114
• For content of the menu: mawk -F: '$3 >= 1000 && $7 ~ /^\/bin\/.*sh$/ {print $1" UID:"$3}' /etc/passwd
  • The second entry is required since whiptail menus always require two array entries each line (one for left side and output value, one for right side description. I have currently no better idea then showing the user ID there 😄.
• Create a new dietpi.txt entry at: https://github.com/MichaIng/DietPi/blob/dev/dietpi.txt#L83
  • AUTO_SETUP_AUTOSTART_LOGIN_USER that is set to root by default.
  • Scan this setting for menu pre-selection and as well use this, when running dietpi-autostart non-interactively via index as command argument, e.g. dietpi-autostart 2 to enable desktop login without any prompt. This is e,g. done on first run installs: https://github.com/MichaIng/DietPi/blob/dev/dietpi/dietpi-software#L14865
    • Could be moved to firstboot (to apply autostart choice even without internet), but it needs to be assured that related software is already installed. Not sure currently if this is checked at best within dietpi-autostart to in case revert selection, or in dietpi-login to simply skip starting a non-existent executable/service and print an error on login instead. I think the latter makes sense. Currently it is even offered to select an autostart option when selecting an autostart capable software title within dietpi-software BEFORE it got installed, so it loads automatically on reboot.

[FredericGuilbault]

Jep the DietPi-PREP behaviour of course would be changed then, to simply create dietpi as system user via useradd -r dietpi .... It will most likely get ID 999 then (if free), however assured one <1000.

My point was that as it's hard coded that PREP_SYSTEM_FOR_DIETPI.sh will create user dietpi with UID 1000. ( And we could even force it with useradd --uid 1000 ) So we can rely on this. But if we implement dialog. There is no need to have a known UID to rely on.

I would have been ok with not having a dialog for user selection. Simply be able to auto-login as default user is enough for me. I won't create any other users. But im not aganst it if you are motivated let's go.

Unlikely someone does this, but to be failsafe we could check /etc/passwd or getent passwd for a valid login shell as well. But perhaps a bid overkill.

I think it's overkill, When a user mess with am OS at this level, I think he/she can assume the things he break, I don't think anyone will be mad at dietpi if they both have created the user with no shell and enabled auto-login on it.

Do you really care about the menu for user selection ?

[MichaIng]

@FredericGuilbault
Yeah, the thing with dietpi being system user and allow to auto-create any new user on firstboot, is something I will not implement with v6.25 at least. But since it is/solves some other requests/issues reported, I am just thinking long-term here.

For now having the login user choice and a related dietpi.txt setting will do. I will simply add a note that of course this user must exist (means on fresh DietPi images only root and dietpi will work), otherwise it is reverted to root automatically. Same for the autostart option itself. Having some failsafe binary/service checks before attempting to start them, makes sense anyway, and the same will do for the user, when creating the drop-in config for autologin.

For Lysmarine OS this has the advantage that you could pre-create a lysmarine on your images e.g. to make that more prominent, and set this as default login user, in combination with a desktop e.g., just as an idea.

And yeah, similar to the autostart setting in dietpi.txt, it will not lead to any prompt, the setting will be silently applied (based on dietpi.txt entry and if user exists) for now as it was inside dietpi-software, in future version I will move this to firstboot to not rely on network.

I think it's overkill, When a user mess with am OS at this level, I think he/she can assume the things he break, I don't think anyone will be mad at dietpi if they both have created the user with no shell and enabled auto-login on it.

Yeah, note that since DietPi aims to make it easy for unexperienced users to apply certing software and settings to their OS, we have a relatively unexperienced user space in average. So it does not hurt to implement things failsafe here, and the above mawk has one simple additional conditional statement, so really no big deal 🙂.

[MichaIng]

Okay I close this PR and work on the implementation as discussed here: #2930

Merged, ready for testing.
If the user does not exist and is forcefully added to the drop-in config, the login fails and agetty breaks, which means you are cannot login without manually fixing and restarting the [email protected]. So the sanity (existence+shell) check makes sense.

[FredericGuilbault]

Im good with this.

I must say the user 999 still bug me but in not aware of all the usecase. Im trusting you anyway. So I won't argue on this.

[FredericGuilbault]

Ur fast :D

[MichaIng]

@FredericGuilbault

I must say the user 999 still bug me

What you mean by user 999?

[FredericGuilbault]

@MichaIng

This,

And I aim to make dietpi itself a system user by times, instead allow to create a custom user on first login.

I taught system user where implying < 1000

[MichaIng]

@FredericGuilbault
Exactly. So one will not be able to use "dietpi" as login user on fresh images, but instead create a custom user, as well via dietpi.txt.
There have been some concerns that a second login user beside "root" implies a security risk if users are not aware of this existing. Others create a custom user account and are annoyed by "dietpi" showing up on graphical login masks, without being able to remove it, because it is expected/required in many DietPi scripts (especially dietpi-software).