[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [E-devel] Desklock



On Mon, 6 Mar 2006 19:44:38 -0800 (PST) Eric Sandall <eric@sandall.us> babbled:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Thu, 2 Mar 2006, Carsten Haitzler wrote:
> > On Wed, 1 Mar 2006 13:38:16 -0800 (PST) Eric Sandall <eric@sandall.us>
> > babbled:
> >> On Wed, 1 Mar 2006, Carsten Haitzler wrote:
> >>> On Tue, 28 Feb 2006 10:59:27 -0800 (PST) Eric Sandall <eric@sandall.us>
> >>> babbled:
> >>>> On Tue, 28 Feb 2006, Aleksej Struk wrote:
> >>>>> The feature is still under development. Actually, the unlocking
> >>>>> through the user system wide password will be implemented too.
> >>>>> For now, the personal desklock password is, more or less, a temporal
> >>>>> feature.
> >>>> <snip>
> >>>>
> >>>> As I'm not the one coding this I probably don't have much input ;),
> >>>> but IMO the only password allowed should be the already setup user
> >>>> password, not Yet Another Password that the user has to define and
> >>>> remember (though they could use the same password as their account
> >>>> password, but then that opens up 'security' issues with who gets
> >>>> access to where this password is stored, is it encrypted, etc.).
> >>>
> >>> the problem is - to handle the "user password" is a massive pain in the
> >>> arse. you need to use PAM or getpwent() and this presents some serious
> >>> problems. what if your user account details live in an ldap db? sure - pam
> >>> wraps this and handles it, but now we bind ourselves to pam - which is a
> >>> bit problematic to use in a portable way even between linux distributions.
> >>>
> >>> also note - this is no worse than leaving your desktop unlocked and
> >>> someone walking by and going "rm -rf ~/*" in a terminal. if you walk away
> >>> from your machine and leave it unlocked - it's fair game for ANYTHING.
> >>> someone locking it with a pw u don't know is fairly harmless compared to
> >>> other things they can do.
> >>
> >> Shouldn't desklock just use xscreensaver then? That would take care of
> >> all the authentication (unix, PAM, KRB5, etc.) for us as well as
> >> providing various backgrounds (as mentioned in the other thread)
> >> through the screensavers. It'd also save duplicating a lot of work,
> >> IMO.
> >
> > u can bind this to a key and exec xscreensaver to lock already - u have
> > been able to do that ever since. e's lock is separate and independent of
> > xscreensaver.
> 
> I thought DeskLock was just wanting to lock the screen for you, which
> is what xscreensaver does well already, that is why I mentioned it.
> One could have DeskLock optionally depend on xscreensaver for the
> system user accounts (LDAP, unix, etc.) is what I was trying to say,
> rather than having to reinvent the wheel.

e's dependencies are set in stone - this would be a large lump of dependency for a very small feature. you have a choice - use xcsreensaver, or use e's lock. e's lock can't use your system password (yet).

> - -sandalle
> 
> - --
> Eric Sandall                     |  Source Mage GNU/Linux Developer
> eric@sandall.us                  |  http://www.sourcemage.org/
> http://eric.sandall.us/          |  SysAdmin @ Inst. Shock Physics @ WSU
> http://counter.li.org/  #196285  |  http://www.shock.wsu.edu/
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2.1 (GNU/Linux)
> 
> iD8DBQFEDQGoHXt9dKjv3WERAvyiAKCvaqPeNtwXQdm0qrjSIPuz2r/CGQCgxW6K
> yE/YoSAFCAaKCn44CVwXlzw=
> =V7lm
> -----END PGP SIGNATURE-----
> 


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster@rasterman.com
裸好多
Tokyo, Japan (東京 日本)