[Tech] password in guest session

[Michael Paoli]

Hmmmm, not sure about "session", but ...
In general, if password isn't set on account, user can set password on
their account.  E.g. they use passwd command, or take most any action
(e.g. GUI) that lets them set/change their password, and they can
set/change their password - if no password is present, they don't have
to provide old password to set a new one.

So, ... is password set on account?  Again, I don't know about "session",
but it's pretty easy to see if password is set on account.
As root (using sudo, or whatever), have a peek at the file
/etc/shadow
It's colon (:) separated data (see also shadow(5)).
Do NOT edit that file directly; do notice the account in question,
notably line for guest which will be guest in the first field (if
that in fact is the account name).  Oh, and don't show us any
of the 2nd field data (lest folks on 'da Internet be cracking
passwords - this is also publicly archived list).
If the 2nd field is empty, there is no password on the account.
If the 2nd field isn't empty, a password will be prompted for
(and there may or may not be a password that works, depending on
what exactly is in the field - typically it would be a form of
salted hash of the password, but it could also be certain strings
which will never match a password to the data in the field, e.g.
if the strings is or starts with * or ! it is unmatchable, and in
the latter case, also locked.

In any case, one can prevent a user, e.g. guest, from setting or
changing their password.  This is done by using password aging.
Password aging is generally used to do things like force a user
to change their password - but likewise it can also be used to
force a user to never be able to change their password - the
latter probably being what you want in this case.

So ... how would we set aging so user can't change their
password, and also remove user's password?  As root,
would do something like this (where I show leading
"# " as root's PS1 prompt):
# chage -E -1 -I -1 -M -1 -m 99999 -W -1 guest && passwd -d guest
The first bit of that disables all the aging, except setting a minimum  
number of
days between password changes of 99999 (see also further below), and  
the second
part removes any password that's present on the account.
And, example showing that they then can't change it (except on the host
I tested on, I used account test, rather than guest):
$ id -nu
michael
$ su - test
test at debian:~$ id -nu
test
test at debian:~$ su - test -c 'echo did not ask for password as there is none'
did not ask for password as there is none
test at debian:~$ passwd
Enter new UNIX password:
Retype new UNIX password:
passwd: Authentication token manipulation error
passwd: password unchanged
test at debian:~$
And yes, works essentially same on {U,Ku,Lu,Xu}buntu.
Notice in the above, when I used su (not sudo) to go from non-root  
account to test,
it didn't ask for password - as there is no password on the account.
I showed that again using another su command as test to emphasize the point.
Using the passwd command, note that it didn't first prompt for  
old/existing password,
as account still has no password.  And although passwd accepted the  
two matched
passwords given to it to change to, it failed, on account of the  
password aging
restrictions.  Notably we told it the password cannot be changed for  
99999 days
since last change (the epoch, since we don't have an earlier change date).
That's minimum number of days between changes.  Max isn't set, so is treated
as no maximum.  And with minimum larger than maximum, it disallows  
change, hence
the change attempt fails.  One typically wouldn't totally disallow a user to
change their password, but this would be one of the exceptional circumstances
where one would want and need that to be the case, and the aging setup I gave
would enforce that.  That would work for any account except superuser (root),
anyway - root isn't bound by and/or can override password restrictions  
and aging
settings for any and all accounts.
Also, don't use value larger than 99999 - that appears to be default  
max - and quite
long enough for our purposes.  Larger values may have issues (e.g. may  
set it, then
be unable to change it - even by root with passwd or chage - looks  
like I found a
slight bug).  And -1 generally removes/disables the respective aging bits.
Note however that 0 is special, at least for date of last change (days since
epoch) - in that case 0 is treated as expired now and must change upon use.
Note that some aging information can possibly conflict, so typically  
don't want
to do that (one may not get expected results).  But the combination of aging
information I used is fully allowed, and prevents the user from changing their
password, and that's generally the case where the setting for minimum  
number of
days between password changes is set to value larger than the maximum  
number of
days between password changes.

> From: "Christian Einfeldt" <einfeldt at gmail.com>
> Subject: [Tech] password in guest session
> Date: Wed, 29 Jun 2016 22:49:10 -0700

> Hi,
>
>  I have been told by one of the residents at the Crosby that someone put a
> password on the guest session of one of the machines, locking out the
> residents.  Here are my questions:
>
>
>    1. Is it actually even possible to put a password on the guest session?
>    I am not talking about the guest account.  I am talking about the guest
>    session that reverts to default settings after each log-out.
>    2. If so, is there a way that I can prevent this from happening again in
>    the future?
>
> Thanks in advance!
>
> --
> Christian Einfeldt