[meta] help?
Did a teensy bit 'o searching regarding /etc/subgid.lock on *Debian* - and found almost, but not quite nothing. Looks to be rather Lubuntu specific. The bit I did find on Debian related to Debian detecting difference in Lubuntu specific patch not in Debian. http://lists.alioth.debian.org/pipermail/pkg-shadow-devel/2016-February/0108... http://lists.alioth.debian.org/pipermail/pkg-shadow-devel/2016-February/0108... diff -pruN 1:4.2-3.1ubuntu1/debian/passwd.service 1:4.2-3.1ubuntu2/debian/passwd.service --- 1:4.2-3.1ubuntu1/debian/passwd.service 2016-02-01 20:35:12.000000000 +0000 +++ 1:4.2-3.1ubuntu2/debian/passwd.service 1970-01-01 00:00:00.000000000 +0000 @@ -1,10 +0,0 @@ -[Unit] -Description=Clear passwd locks - -[Service] -Type=oneshot -RemainAfterExit=yes -ExecStart=/bin/rm -f /etc/gshadow.lock /etc/shadow.lock /etc/passwd.lock /etc/group.lock /etc/subuid.lock /etc/subgid.lock - -[Install] -WantedBy=multi-user.target diff -pruN 1:4.2-3.1ubuntu1/debian/passwd.tmpfile 1:4.2-3.1ubuntu2/debian/passwd.tmpfile --- 1:4.2-3.1ubuntu1/debian/passwd.tmpfile 1970-01-01 00:00:00.000000000 +0000 +++ 1:4.2-3.1ubuntu2/debian/passwd.tmpfile 2016-02-04 22:00:50.000000000 +0000 @@ -0,0 +1,8 @@ +# If a password operation is in progress and we lose power, stale lockfiles +# can be left behind. Clear them on boot. +r! /etc/gshadow.lock +r! /etc/shadow.lock +r! /etc/passwd.lock +r! /etc/group.lock +r! /etc/subuid.lock +r! /etc/subgid.lock
Curious also, when the file was present, did you use fuser(1) or similar to see if anything still had the file open? Was the file also possibly non-empty in size, and possibly contained a PID or the like? And if so, did that PID still exist and what was it? Did fuser(1) or lsof(8) show any process having open for write/append, or having any lock on /etc/passwd, /etc/shadow, /etc/group, /etc/gshadow, or any of the lock files thereof?
More [meta] help ... been thinking of this for the "mom" computer, or similar for [great]grand{ma,dad}, etc. Notably where remote access - e.g. to troubleshoot/support, could be quite useful, but computer may typically be behind NAT/SNAT on The Internet and/or have dynamic IP(s), etc. - so not so feasible to run an ssh server there and just use ssh to access the computer. ... well, "reverse ssh" ... I remember someone asking the question a *long* time ago, and ... someone else's excellent response. I don't recall much of the detail of the response anymore, but key bit I do recall of it, was using ssh port forwarding, so, effectively, the computer would do a "call home" to some Internet accessible server ... which would then cause port to be opened on that Internet accessible server - one could then ssh to the desired target computer via that port. E.g., have done bit of proof of concept testing on that, and essentially works fine. On the target ("mom") computer, set up ssh server ... but configure it to only listen on localhost (127.0.0.1 and ::1). Set up account(s) as relevant (for the port forwarding, etc.), and generate ssh key pair on the target computer. Set up ~/.ssh/authorized_keys on (Internet accessible) server computer, with it configured using that public key and forced command and otherwise as restricted as feasible, so all it can do is set up the port forwarding - nothing else. Create suitable service(s) (e.g. crontab jobs or whatever) for the target computer to set up and generally maintain those port forwarded "phone home" ssh connections. The forwarding should be to localhost (127.0.0.1 and/or ::1) on the server computer. I'm presuming the target ("mom") computer may not have the world's best passwords - so don't want its ssh server exposed to The Internet ... even if it might sometimes be out somwhere where it gets a directly accessible Internet IP address. So ... I think folks can figure out the details from there ... essentially target creates tunnel, opening up some (>=1024) port on localhost of server, which is forwarded over ssh tunnel created by target, to port 22 of localhost on target. That's essentially it ... have tested it out fair bit, and works fine. So long as target can make outbound TCP connections to port 22 of server - even through NAT/SNAT - that will then generally allow ssh access to target via server. And, of course, once one can do that - and noting also that one can ssh into server, one then has means to ssh from The Internet into target (via server), and can also do, e.g. X11 forwarding, set up other software if/as needed on target or enter various commands/data (e.g. activate something to be able to view full desktop of target, etc.).
Anyway, thought, e.g. Partimus, and others, if they'd not thought of or considered that before, that type of "reverse ssh" can be quite useful for remote support, where NAT/SNAT, dynamic IPs, firewall(s), etc., would otherwise make it unfeasible/impossible to access the target via ssh from The Internet.
Also, if target can access port 443 on The Internet, but not port 22, there are ways of dealing with that ... at least if target isn't being forced through proxy at HTTP/HTTPS layers. I forget the name of the software/package, but, can even be done where both HTTPS web server and ssh effectively listen on port 443 ... there's bit of differences in the protocols - notably whether client or server "talks" first ... and ... that's enough to wedge a little bit of software on port 443 between https and ssh servers - and it can then get the traffic appropriately to either, depending on whether client is ssh or https.
From: "Elizabeth K. Joseph" lyz@princessleia.com Subject: Re: [BALUG-Talk] Lubuntu 14.04 guest session login failure Date: Sat, 8 Jul 2017 20:10:12 -0700
On Mon, Apr 3, 2017 at 11:20 PM, Christian Einfeldt einfeldt@gmail.com wrote:
Hi,
I am experiencing a very strange thing for which there are no ready answers by googling. I am a volunteer for a non-profit which puts GNU-Linux computers in low income shelters. They are stand-alone machines connected directly to the Internet via a hub on a dedicated ethernet cable.
The shelters don't want the users to be able to store anything directly to the machine's hard drive. To give them that functionality, we ask them to use the guest session, which wipes out all data by default when the session ends.
Right now, however, we are experiencing a failure of logging into the guest session. Normally, you just choose the guest session in the Lubuntu login screen, and hit enter, and it boots up a full guest session. No password is required.
Now, when I chose the guest session and hit enter, the system appears to head toward a normal login, but then quickly fails and returns to the login screen.
The system's SU admin account is performing normally. To get into the admin account, I just choose it in the login screen, enter the password, and the admin session boots up normally.
This whole thing is very strange, and I have never seen anything like it before. We are using 14.04 on 13 machines with identical or similar hardware and are not having any such problems. This email is being written on one of those such machines, and the guest session works just fine.
I ran updates on the malfunctioning machines, rebooted, no joy.
Thanks very much in advance.
In case anyone was curious as to what happened with this, I finally had some time to sit down on site this evening and do some debugging.
Some background as to how the guest logins work in Lubuntu: A guest-XXXXX (random characters) user is created upon login, which is used throughout the session. It is then deleted when the user logs out.
After some red herrings in the auth logs (mostly PAM errors around KDE and Gnome keyrings), I did some digging in the lightdm logs. Eventually I noticed the UID of the guest account trying to be created was the same every time a login attempt was made: 999. Odd. So I looked in /etc/passwd and noticed that there were hundreds of guest-XXXXX accounts. That's no good!
Turns out, at some point the /etc/subgid.lock file got stuck in an existing state (wasn't deleted when the lock concluded), which meant the command to delete the user was not completing successfully upon logout. Users were piling up and never being deleted. Once the UIDs hit 999 it was failing to create new guest users, so the login would fail. I quick mv (rm didn't work) of the subgid.lock file and a script to delete all the guest accounts got us going again.
I'm considering my options to get us out of this reoccurring issue in the future. I'm thinking of just a cron job on each machine that checks for a subgid.lock file sticking around for more than a couple days and moving it out of the way, but I'll sleep on it. More clever suggestions welcome ;)