Re: Lockdown stuff

[George <jirka 5z com>]

On Mon, Sep 22, 2003 at 07:41:19PM -0400, Jonathan Blandford wrote:
> > Here's what I have on lockdown currently, sort of just a draft quality
> > of course.
> 
> It's a nice summary, and good starting place for the discussion.
> 
> > Different lockdown goals:
> > 
> >   1) Full lockdown (public access terminal)
> >   2) Partial lockdown (corporate desktop to ease support, panel locked,
> >      but user can read write files and all launch apps and change some
> >      prefs)
> >   3) Minimal lockdown of certain parameters
> >      (lockdown of specific config parameters while leaving
> >       rest relatively free.  Perhaps forcing a panel of
> >       company 'mandated' launchers, etc...)
> 
> Small, medium and large; sounds good.  The only thing I'd add to it is
> that GNOME doesn't necessarily have to do everything.  We can use acl's
> to prevent people from running programs, and in general lock down the
> box beyond GNOME's ability to.  I think for full lockdown (Case 1), we
> should work with that.  It will make our life much easier, anyway.

Obviously, however we have to support the GUI to work properly.  For example
we really shouldn't show programs that don't exist.  However that is possible
to do with user permissions (locked out users have no read privilages for the
particular .desktop)

> >   I'm not sure of the control center status, but I think for that what we
> >   have suffices as long as the UI respects key-writability (which I suppose
> >   it doesn't currently).
> 
> It should be relatively easy to get this going.  I meant to do this for
> 2.4 but it slipped through the feature freeze.

Well, it's not really a 'feature' to respect key-writability.  Making a key
not writable is possible, having the UI go whacko when it encounters such a
key is a bug.  The only freeze that should apply here is hard code freeze.

> > #include <rant-on-how-simple-this-would-have-been-if-we-used-pong.h>
> 
> Rather than just #including a rant, lets talk about reviving either the
> pong code base or it's functionality.  I know we've had this talk on irc
> before, but the GConf <-> GTK+ mapping is done too many times to let
> people keep reinventing it.  We need to have a solution for this in the
> supported platform.
> 
> So, George, what do you think about pong's current state?  Does it make
> sense to port it to GTK+ 2.0 and try to get it into the platform?  I'm
> not super thrilled with GConfPropertyEditor in the control-center, and
> would switch to something better.

pong current state in cvs is 'half ported to gtk+2'.  I think it might be
easier to start with pong then to start from scratch.  Some things in pong
can obviously be whacked.  Pong has pretty good docs:

Web: http://www.jirka.org/pong.html
Documentation: http://www.jirka.org/pong-documentation/index.html

The docs should give you an idea of how pong works and all that it does (or
did since now it's half ported and dead).

I think in theory the way pong works is the right way.  The pong config file
is really what ties all the info together and has a lot of semantic info
about your app and it's properties then you could reasonably build into
glade.

Really I think 90% of all preference dialogs can be done with just simple
semantic information and need not involve glade.  For example panel as it
right now is could be done without glade completely since there is no really
complicated layout info involved.  This way you can track changes to HIG far
better too since you don't store the detailed layout but just enough to build
the thing.  Of course pong supported using glade for either parts of the
dialog or the whole dialog.  You could also plug in bonobo widgets for truly
custom parts of the dialog, or you could really provide your own plugin
mechanism doing things very manually if you wanted.

Most people had the wrong idea that pong somehow generated dialogs by itself
from schemas or some other nonsense.  No, there is a simple layout language
in pong.  Simple because it doesn't need to be complex.  Anyway read the
docs.

Obviously lots has to be whacked/changed from pong to be useful for gnome2,
a lot of it is still kind of gnome1.4 mentality.

> >   For partial lock down, I think it suffices to make it possible to lock down
> >   a specific panel rather then going down to individual applets.  You can
> >   do individual applets (especially launchers) with the key-nonwritability
> >   stuff anyway.  The thing is that I could just HIDE or MOVE the panel with
> >   the locked applets such that they would in effect be no longer available,
> >   so I think it kind of defeats the purpose.  On the other hand having a
> >   whole panel locked down means I could force say a bottom panel with menus
> >   and launchers set by the admin and disallow the user to change this panel,
> >   but the user could add a new panel to have some personal setup.  The bottom
> >   panel would be unmovable and always there so that support could rely on
> >   having this panel always there for users.  Again all applets and objects
> >   on this panel act as locked down so you can't change their setup either.
> >   In effect it's just as locked down as in full lockdown except it's only
> >   this panel.  The key for that is:
> >     /apps/panel/profiles/<profile name>/toplevels/<panel name>/locked_down
> 
> What's the difference between an applet being locked down and all it's
> keys non-writable?

locked down is a very semantic thing the applet can act on (currently I made
applets just not show the properties window).  Keys not being writable you
MUST handle per key.  You will therefore show a grayed out properties window
which is weird.  Also an applet can be locked down on a locked down panel,
no need to try to read the docs for every applet to see what all keys to
make non-writable.

> As an alternative key name, how about 'disable_command_line'.  'inhibit'
> is a little weird to me.  Also, what exactly do you mean by
> command_line?  Perhaps we should have a few more keys here to be more
> explicit.  Do we want to avoid running of arbitrary binaries?  Permit
> only launchers that we allow?  Perhaps thinking a bit of the actions
> that we need to control would be good.  For comparison, here's what KDE
> does here:
> 
> http://webcvs.kde.org/cgi-bin/cvsweb.cgi/kdelibs/kdecore/README.kiosk?rev=HEAD

Command line is currently taken as "inhibit/disallow/disable running running
arbitrary binaries".  All existing launchers are obviously allowed.

> To be perfect, we'll probably have to count on the system to help out.

Obviously.  We should however get as close as we can I think.  Since for 99%
of applications it will be enough.

> >   The last thing implemented is locking down the ability to "force quit"
> >   an app.  I suppose some places might want an 'always on' app that can't
> >   be quit.  If we allow 'force quit' from the panel (or elsewhere) the
> >   user could just whack it.  I don't think this needs to inhibit the
> >   metacity 'app is not responding to close, want to whack it' dialog
> >   since such an app would respond to close by not wanting to close
> >   and would never be 'non-responsive'.  The key for this currently
> >   is:
> >     /desktop/gnome/lockdown/inhibit_force_quit
> 
> I don't like this option, anyway.  We should make it always on.  (=

But there are places where I don't want this to work.  It is dangerous
for public access terminals.  Or even corporate desktops.  Anywhere where the
sysadmin wants to force something on screen.  If you can force quit things
then you can remove locked things really ...

> [ Same comment above about 'inhibit' applies here, too ]

I actually like 'inhibit' better then disable :)

> >   Control Center:
> > 
> >     Needs to follow key-writability in the UI.  I haven't looked at
> >     this much.  For scenario #1 you'd probably not want this in the
> >     menu at all.
> 
> Should be easy to do.  The only problematic thing here is that sometimes
> a given setting is compromised of a set of keys.  The big examples here
> that I can think of are the theme manager and the background dialog.  In
> addition, we should probably disable the whole dialog somehow if you
> can't write to any of the keys.  That fits more into the menu discussion
> though.

This is the way I solved this in places where we needed atomic changes in the
panel.  If you can't change all the keys you'd need to change for an action,
you can't do the action.

George

-- 
George <jirka 5z com>
   If Christ were here now there is one thing he would not be - a Christian.
                       -- Mark Twain