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

Re: Open Xlock as root

My main point is you need to think about a policy about this.  Why is
xlock being run where the admin needs to kill it?  The admin has physical
access to the machine in question already, and should have remote acess.

If you are dealing with an xlock "situation" in public clusters, then you
need some way to stop it.  At an educational instution I have worked in,
they made xlock have a 10minute timer on it.  After this timer ran out, a
KILL ALL button appeared so someone could come in and claim the abandoned

The original poster may have more of a problem that needs to be solved
socially, rather than technically.  

As for asking for different passwords, I've implemented this with the
kerb5 pam module by adding an "inst" option so that you can auth with
different instances of your password.  I need to publish the code changes
still though.  This is useful to allow a different passwords for things,
like insecure mail pop accounts vs. shell logins. :)

-Matt Drown     -- Privacy, Anonyminity, & Security -- DataHaven Project
 panzer@dhp.com -- Shell and Web accounts           -- http://www.dhp.com/ 

On Tue, 7 Dec 1999 william.evans@computer.org wrote:

> >>>>> "Matt" == Matt Drown <panzer@dhp.com> writes:
>     Matt> Isn't this a moot point as anyone can walk up to an annoying xlock screen
>     Matt> under xfree86 and hit ctrl-alt-backspace? :)
>     Matt> You could put the root password in /etc/passwd file with normal encryption
>     Matt> and it should work also.  Pam can read crypted passwwords here without
>     Matt> root privs?   Sounds bad doesn't it?
>     Matt> At this rate, you should just hack up xlock to have a backdoor password it
>     Matt> retrieves from some other location, if you want to keep xlock in general.
> This is not a good solution, IMO.  It may work, and on non-PAM
> systems it's probably the only way to get it done.  However:
> First of all, we'd like to be able to put this functionality into
> other apps, too, not just xlock, so we'd have to modify each source
> individually.  This was one motivation for PAM in the first place: not
> having to modify every app when a new security option is introduced.
> Second, it forces the option, where some sysadmins will specifically
> not want it enabled.  If you wanted to make it an option, then the
> user could prevent it's being used, anyway, which undermines one
> reason for having it there.
>     Matt> The next modification is of course to have it prompt for a
>     Matt> password before it locks the screen also.
> This would really be a good idea, and perhaps the xlock developer(s)
> should hear of this.  However, this doesn't really change what we are
> trying to accomplish, and that is a password that can override the
> user's xlock.
> -bill
> -- 
> William Evans                 < william . evans @ computer . org >

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