Re: xscreensaver vs gnome-screensaver



On Fri, Feb 17, 2006 at 02:09:16AM -0800, mali wrote:
>    1) PAM should be driving the unlock GUI instead of the GUI driving the
>    PAM  code.  In  xscreensaver a serious flaw of logic is the assumption
>    that  a  locked  screen will always require a username and password to
>    unlock.
[snip]

Agreed.

>    2)  As  soon  as  the  screen gets locked pam_authenticate needs to be
>    called  and  code  should  loop  inside the pam_conversation function.
>    Currently,  pam_authenticate  gets  called  only when a user moves the
>    mouse or keyboard while the screen is locked.

I don't see what's to be gained by doing this, and the possibility of
combining modules which lock a user out after a given number of failed
attempts (pam_tally) with modules for which timing is important makes me
think it's a bad idea.

>    4) For audit code to have any validity, unlocking should not fall back
>    to  the  mechanism of comparing passwords to /etc/password entries and
>    authenticating  without  PAM.  Only  PAM  should be the authentication
>    policy  and  no root passwords be allowed to unlock the screen, breaks
>    auditing  again.  If  authentication  through PAM fails, screen is not
>    unlocked.

Agreed: if PAM is being used, nothing should bypass it.

>    5)  I  am not sure if gnome-screensaver is setuid root program(?), and
>    it has to be, to read /etc/password and make PAM calls, then how is it
>    handling  the  unlock GUI based on libgtk, as libgtk exits if a setuid
>    root program calls any functions in libgtk.

It is not setuid on systems where PAM is available, but is setuid
everywhere else.  Does PAM authentication require superuser privileges
on any OSs?  I'd expect that sort of work to be farmed out to a
module-specific setuid helper or long-running daemon (a la Linux-PAM's
pam_unix.so or Samba's pam_winbind.so).

[snip]
>    In  xscreensaver  the  unlock GUI which is gtk based was turned into a
>    separate  helper  program  by  ximian.  This  helper  GUI  ran with no
>    privileges  and  would  only  get  user  input  and  pass  it  to  the
>    xscreensaver  daemon through a pipe. This did upset Jamie, is slow and
>    potentialy can cause race condition along with other havocs etc.

Do you have a pointer to information about the race conditions this
creates?  I'm curious to find out more.

HTH,

Nalin



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