<div dir="ltr">thanks to everyone who replied to this thread!  working on it at the shelter now.  Thx! </div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 30, 2016 at 3:06 AM, Michael Paoli <span dir="ltr"><<a href="mailto:Michael.Paoli@cal.berkeley.edu" target="_blank">Michael.Paoli@cal.berkeley.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hmmmm, not sure about "session", but ...<br>
In general, if password isn't set on account, user can set password on<br>
their account.  E.g. they use passwd command, or take most any action<br>
(e.g. GUI) that lets them set/change their password, and they can<br>
set/change their password - if no password is present, they don't have<br>
to provide old password to set a new one.<br>
<br>
So, ... is password set on account?  Again, I don't know about "session",<br>
but it's pretty easy to see if password is set on account.<br>
As root (using sudo, or whatever), have a peek at the file<br>
/etc/shadow<br>
It's colon (:) separated data (see also shadow(5)).<br>
Do NOT edit that file directly; do notice the account in question,<br>
notably line for guest which will be guest in the first field (if<br>
that in fact is the account name).  Oh, and don't show us any<br>
of the 2nd field data (lest folks on 'da Internet be cracking<br>
passwords - this is also publicly archived list).<br>
If the 2nd field is empty, there is no password on the account.<br>
If the 2nd field isn't empty, a password will be prompted for<br>
(and there may or may not be a password that works, depending on<br>
what exactly is in the field - typically it would be a form of<br>
salted hash of the password, but it could also be certain strings<br>
which will never match a password to the data in the field, e.g.<br>
if the strings is or starts with * or ! it is unmatchable, and in<br>
the latter case, also locked.<br>
<br>
In any case, one can prevent a user, e.g. guest, from setting or<br>
changing their password.  This is done by using password aging.<br>
Password aging is generally used to do things like force a user<br>
to change their password - but likewise it can also be used to<br>
force a user to never be able to change their password - the<br>
latter probably being what you want in this case.<br>
<br>
So ... how would we set aging so user can't change their<br>
password, and also remove user's password?  As root,<br>
would do something like this (where I show leading<br>
"# " as root's PS1 prompt):<br>
# chage -E -1 -I -1 -M -1 -m 99999 -W -1 guest && passwd -d guest<br>
The first bit of that disables all the aging, except setting a minimum number of<br>
days between password changes of 99999 (see also further below), and the second<br>
part removes any password that's present on the account.<br>
And, example showing that they then can't change it (except on the host<br>
I tested on, I used account test, rather than guest):<br>
$ id -nu<br>
michael<br>
$ su - test<br>
test@debian:~$ id -nu<br>
test<br>
test@debian:~$ su - test -c 'echo did not ask for password as there is none'<br>
did not ask for password as there is none<br>
test@debian:~$ passwd<br>
Enter new UNIX password:<br>
Retype new UNIX password:<br>
passwd: Authentication token manipulation error<br>
passwd: password unchanged<br>
test@debian:~$<br>
And yes, works essentially same on {U,Ku,Lu,Xu}buntu.<br>
Notice in the above, when I used su (not sudo) to go from non-root account to test,<br>
it didn't ask for password - as there is no password on the account.<br>
I showed that again using another su command as test to emphasize the point.<br>
Using the passwd command, note that it didn't first prompt for old/existing password,<br>
as account still has no password.  And although passwd accepted the two matched<br>
passwords given to it to change to, it failed, on account of the password aging<br>
restrictions.  Notably we told it the password cannot be changed for 99999 days<br>
since last change (the epoch, since we don't have an earlier change date).<br>
That's minimum number of days between changes.  Max isn't set, so is treated<br>
as no maximum.  And with minimum larger than maximum, it disallows change, hence<br>
the change attempt fails.  One typically wouldn't totally disallow a user to<br>
change their password, but this would be one of the exceptional circumstances<br>
where one would want and need that to be the case, and the aging setup I gave<br>
would enforce that.  That would work for any account except superuser (root),<br>
anyway - root isn't bound by and/or can override password restrictions and aging<br>
settings for any and all accounts.<br>
Also, don't use value larger than 99999 - that appears to be default max - and quite<br>
long enough for our purposes.  Larger values may have issues (e.g. may set it, then<br>
be unable to change it - even by root with passwd or chage - looks like I found a<br>
slight bug).  And -1 generally removes/disables the respective aging bits.<br>
Note however that 0 is special, at least for date of last change (days since<br>
epoch) - in that case 0 is treated as expired now and must change upon use.<br>
Note that some aging information can possibly conflict, so typically don't want<br>
to do that (one may not get expected results).  But the combination of aging<br>
information I used is fully allowed, and prevents the user from changing their<br>
password, and that's generally the case where the setting for minimum number of<br>
days between password changes is set to value larger than the maximum number of<br>
days between password changes.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
From: "Christian Einfeldt" <<a href="mailto:einfeldt@gmail.com" target="_blank">einfeldt@gmail.com</a>><br>
Subject: [Tech] password in guest session<br>
Date: Wed, 29 Jun 2016 22:49:10 -0700<br>
</blockquote>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
Hi,<br>
<br>
 I have been told by one of the residents at the Crosby that someone put a<br>
password on the guest session of one of the machines, locking out the<br>
residents.  Here are my questions:<br>
<br>
<br></span>
   1. Is it actually even possible to put a password on the guest session?<span class=""><br>
   I am not talking about the guest account.  I am talking about the guest<br>
   session that reverts to default settings after each log-out.<br></span>
   2. If so, is there a way that I can prevent this from happening again in<span class=""><br>
   the future?<br>
<br>
Thanks in advance!<br>
<br>
--<br>
Christian Einfeldt<br>
</span></blockquote>
<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Christian Einfeldt</div>
</div>