Too many temporary users on the login screen.

[SilenceLucid]

Hello, I'm a novice user, I'm having problems with temporary users, numerous temporary users are being created and they are not deleted and these accounts do not appear in the user manager, students spend a lot of time scrolling through the list of temporary users until they get to the right user on the login screen. The laboratory has 30 computers and students take a long time to login. The OP is Linux Mint XFCE 20.3 lts. Thanks.

[Cosmo.]

What you name temporary users is actually named guest account. This is for making the conversation easier.

You have actually found a bug.

If you set to create a guest account the idea is, that anybody logs into it and after finishing his/her job (s)he logs out again. By doing so the used guest account will get closed and you do not see it on the login screen.
In your case the user has selected to switch user and so the guest account does not get deleted. Theoretically the guest user should be able to reenter his/her account and continue the work. Actually this does not work, because the old guest account asks for a password, which obviously does not exist. So it is impossible to renter this account and to close it correctly.
If you would select to log off this would not happen.
Removing those unusable and senseless accounts is easy: Reboot the system.
So far how you can prevent or solve this problem.

I cannot tell, if it is a bug, that a guest can leave the account without logging off or if the bug is the point, where a not existing password gets asked, In any case either the one or the other thing is buggy and needs to get fixed.

BTW: I never saw this bug, because I have no need for a guest account. But after your post I was able to reproduce the issue in a quarter of a hour.

[AZgl1800]

IMO,

if a GUEST user ever has access to a PC, it should be rebooted after they quit using it.

problem is, people who use a 'guest account' are clueless and just get up and walk away, leaving their "login" still active.

IMO, I would install a timer that after XY minutes of no-activity, the system does an automatic reboot.
this for security purposes.

when I was gainfully employed by a government agency, you had 5 minutes to keep your fingers doing something, after that, your account was Logged off and went back to the Main Bootup Login Screen, effectively erasing all history of what you did.

me, being a geek, went into the profile and changed that, as my desk was responsible for taking "Trouble Reports" for failed computer systems, therefore, it was idle for long periods..... IF, I left my desk, I did Control-ESC and it Logged me off and went to the Main User Network Login Screen.

.

[Cosmo.]

I would install a timer that after XY minutes of no-activity, the system does an automatic reboot.

The main user, who is possibly doing some complicated work, will explode with this. (S)he thinks about a task, not about a timer.

[djph]

I would install a timer that after XY minutes of no-activity, the system does an automatic reboot.

The main user, who is possibly doing some complicated work, will explode with this. (S)he thinks about a task, not about a timer.

Then it's complicated.
Look at the output of w; you should be able to see details of the "guest" accounts and what tty / pty they've spawned for themselves.

For example, I run screen for a lot of terminals / to avoid programs getting nuked thanks to a hangup, etc.

Code: Select all

$ w
djph      pts/0    :pts/6:S.0       12:49    4:34  13.97s 13.97s irssi
djph      pts/1    :pts/6:S.1       12:49   16:07m  0.42s  0.42s slrn
djph      pts/2    :pts/6:S.2       12:49   32.00s  0.26s  0.26s mutt
djph      pts/3    :pts/6:S.3       12:49   17:17m  0.05s  0.05s /bin/bash
djph      pts/4    :pts/6:S.4       12:49    5:21m  0.02s  0.02s /bin/bash

As you can see here, "screen 3" has been idle for a little over 15 minutes.

If we look at ps, we can find the login shell's process:

Code: Select all

$ ps aux | grep "pts/3"
djph       2478  0.0  0.0   8164  4956 pts/3    Ss   04:57   0:00 /bin/bash

If I were to kill PID 2478 (i.e. kill 2478), the shell would terminate, and the session would be closed.


basically, your task would be to kill off all the "guest" accounts that have been idle for more than, oh I dunno, 10 minutes?

[Cosmo.]

If a guest account shall possibly stay open (by switch user) is debatable. If the decision for this is no, than the switch user option must get disabled. Simple result: No remaining accounts. No timed whatever and no killing is needed.

If the decision is yes (= the possibility to leave the guest account should be an option), than any timed automatic shutdown for that account would be counterproductive for this design decision. But in any case the demand for entering a password is a bug. This password does not exist and will not exist. Heaven knows, why it gets requested.

There is also a 3rd way thinkable: The guest account can get left without closing it, but if somebody logs as usual into the guest account with the last option in the login screen, (s)he gets automatically set into the already open guest account. In this case there can never be more than one of such open guest accounts and situations as complained by the topic starter cannot happen.

Me thinks, that the possibility to leave the guest account without closing it was not intended by design. If the screensaver starts in the guest account - whether manually or by time-out - the screen does never get locked, although the settings say the opposite (by default: lock immediately). Also you do not get asked for a password, when you want to stop the saver. And there is no option to go to the login screen (e. g. for user switching), as you find it in case of a registered user. So I think, that the possibility to use the switch user option has simply been forgotten for getting disabled.
Another indication for being forgotten: The usual login screen option to enter the guest account is translated, but the indication in case of a left guest account is not, as to be seen on the screenshot of the OP, where you also see, that the string for entering the password is translated. I don't know the OP's language, but I can reproduce it here in a virtual machine.

[SilenceLucid]

Hi there, thank you for everyone's help, I'll add some more information that was missing, just to give a context of the use of the laboratory, computers are used by students and unfortunately, as much as I teach them to log off, there are always students who don't matter and leave the client logged in. I don't accompany them, the teacher does that, I just help with the "maintenance" of the computers. The computer that was logged in goes into hibernation and then everything that I have already reported occurs. Even after restarting the computer, the guest users list remains on the login screen. The guest user is used to make things easier, because when restarting the pc the guest user should be reset/deleted. The language used in the OP is pt-br. I'm using Google translator so maybe there is some inconsistency in the translations. Thank you guys.

[Cosmo.]

The computer that was logged in goes into hibernation and then everything that I have already reported occurs. Even after restarting the computer, the guest users list remains on the login screen.

Launching a hibernated system is not restarting. To get rid of the many guest accounts you have really to reboot the system. This works, as I tested, before I wrote my advice.

Reading your last post I wonder, if using virtual machines is possibly an alternative way to go. I admit, this gives another risk, if the students launch one virtual machine after the other. There will come the point, where not enough RAM is left for the host and the host crashes. Anyway, only you can decide.

[djph]

or, yknow ... they get their own account ....

[Cosmo.]

Might be. But I can imagine that the teacher(s) fear, that the students leave their accounts in a terrible condition just as they do this with the guest accounts. A guest account starts everyday without interaction from the same condition.
Another point might be, that a registered user is - with default settings - able to read data from all other accounts. A guest user cannot do this. So it is possibly a privacy question.

(Damned server, no day without a http 502 error and the infamous Sucuri page, when I do a preview.)

[pbear]

Not sure, but a kiosk account might solve your problem, at least better than what you are doing now.

[djph]

Might be. But I can imagine that the teacher(s) fear, that the students leave their accounts in a terrible condition just as they do this with the guest accounts.

What do you mean "terrible condition"? If you put 30 students on a machine (for example), there will only ever be those 30 accounts on the machine (although, honestly at that point, you'd probably want a central machine running LDAP for centralized user management)

Another point might be, that a registered user is - with default settings - able to read data from all other accounts.

No, regular users cannot see other regular users' data.
You can certainly deviate from the defaults, and make it so that they can view the data ... but that's not "defaults" anymore

[Cosmo.]

What do you mean "terrible condition"? If you put 30 students on a machine (for example), there will only ever be those 30 accounts on the machine (although, honestly at that point, you'd probably want a central machine running LDAP for centralized user management)

If you look at the picture in post #1 than you see it. So much guest accounts, that an inexperienced person might easily think, that the regular accounts have vanished. And obviously nobody there did ever reboot the machine, those countless[1] accounts did not get created in a few minutes. I can easily imagine, how a similarly used usual account looks like after a more or less short time. And the effort to bring it back to defaults is in case of a usual account much greater.

[1] "countless", because it is impossible to tell, how many of them do additional exist above and below the visible part of the login screen.

No, regular users cannot see other regular users' data.
You can certainly deviate from the defaults, and make it so that they can view the data ... but that's not "defaults" anymore

This sounds, as if you never did that. You have now 2 choices: Either you believe me (I don't believe, that you believe me) or you create a second account (no guest account) and try from this new account to read (or copy) anything from your main account. This does work and it cannot be different, because the default umask value is 0002 (look up in your terminal). This is the result of the umask value as set in /etc/login.defs and USERGROUPS_ENAB yes in the same file. - In clear words: Anybody can read your files, as long as you have not manually changed the rights.

You have also a 3rd choice: Read https://www.cyberciti.biz/tips/understa ... usage.html

[djph]

What do you mean "terrible condition"? If you put 30 students on a machine (for example), there will only ever be those 30 accounts on the machine (although, honestly at that point, you'd probably want a central machine running LDAP for centralized user management)

If you look at the picture in post #1 than you see it. So much guest accounts, that an inexperienced person might easily think, that the regular accounts have vanished.

Yeah, but if you gave all the users their own account, there'd only need to be those N users. It wouldn't keep exploding over time into this mess of "guest" accounts today.

No, regular users cannot see other regular users' data.
You can certainly deviate from the defaults, and make it so that they can view the data ... but that's not "defaults" anymore

This sounds, as if you never did that. You have now 2 choices: Either you believe me (I don't believe, that you believe me) or you create a second account (no guest account) and try from this new account to read (or copy) anything from your main account.

No, more that one forgets after 15 years that the first thing your setup scripts do on fstab is set the /home mountpoint to 077

[Cosmo.]

It wouldn't keep exploding over time into this mess of "guest" accounts today.

Nothing would explode, if the bug would not exist. You cannot make a user, even less an inexperienced user, responsible for this bug.

[SilenceLucid]

Hi guys, I'm going to follow the suggestion of creating a standard account, since the problem it's a bug. Even if anyone knows an app to make Freeze, I'd appreciate it. I found this Ubuntu 10.04 LTS command on google, I don't know if it's safe to use it in Mint:

Code: Select all

sudo su -

# for i in `cat /etc/group | grep ^freeze | cut -d: -f4 | sed "s/\,/\ /g"` ; do gpasswd -d "$i" freeze ; done
# groupdel freeze

And one last question, is there a way to make a “.bat” to delete all the contents of the user's default folders (Download, documents, Image...) when the OP starts.

If all goes well, I'll do the default account with the frozen settings and delete any content produced.

Thank you very much for taking the time to help us, inexperienced user.

Edit:

I found an application for freeze, I'll leave the name in case someone needs it too, Deep Lock.

[pbear]

... delete all the contents of the user's default folders (Download, documents, Image...) when the OP starts.

Never done it myself, but my understanding is that's what a kiosk account does.

[SilenceLucid]

... delete all the contents of the user's default folders (Download, documents, Image...) when the OP starts.

Never done it myself, but my understanding is that's what a kiosk account does.

I will try that. Thanks.