[Tech] password in guest session

Christian Einfeldt einfeldt at gmail.com
Thu Jun 30 14:03:10 PDT 2016


thanks to everyone who replied to this thread!  working on it at the
shelter now.  Thx!

On Thu, Jun 30, 2016 at 3:06 AM, Michael Paoli <
Michael.Paoli at cal.berkeley.edu> wrote:

> 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
>>
>
>


-- 
Christian Einfeldt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.partimus.org/pipermail/tech-partimus.org/attachments/20160630/0460a976/attachment.htm>


More information about the Tech mailing list