[BALUG-Talk] Lubuntu 14.04 guest session login failure ... and ... remote support via ...

[Michael Paoli]

[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/010865.html
http://lists.alioth.debian.org/pipermail/pkg-shadow-devel/2016-February/010867.html
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 ;)