Re: Blocking Access (UPDATE)


If a machine is serving multiple users, not installing a feature will
disable it for all users.

If you want to implement a policy for controlling access, it makes
sense to:

a) provide a configuration option to prevent the feature being advertised
  (ie. drop it from menus, panels, desktop workspace, etc.); this
  requires that the configuration contains a list of the features
  (app/applet/capplet/bonobjects) that the user may (or may not) add to a
  feature UI (like a menu)

b) if you really don't want the user to access it,  you should implement
  an access control policy; one interesting trick that's just occurred
  to me is to have the feature attempt to get read access on a file
  in a system directory (e.g. $GNOME/etc/feature.conf); if it can't
  read the file (due to user/group/other permissions OR also due to
  ACLs on the file), then the feature knows the user shouldn't be able
  to access it; this is better than changing permissions on an executable
  file as you want to be able to give a sensible error to the user, not
  just terminate because you can't execute an app or load a shared library
  to resolve some symbols

>Delivered-To: gnome-2-0-list gnome org
>From: SoloCDM <deedsmis aculink net>
>X-Accept-Language: en
>MIME-Version: 1.0
>To: Miguel de Icaza <miguel ximian com>
>Cc: "Gnome-List (Request)" <gnome-list gnome org>, "Gnome 2.0 (Request)" 
<gnome-2-0-list gnome org>
>Subject: Re: Blocking Access (UPDATE)
>Content-Transfer-Encoding: 7bit
>X-BeenThere: gnome-2-0-list gnome org
>X-Loop: gnome-2-0-list gnome org
>X-Mailman-Version: 2.0beta5
>List-Id: Discussion about GNOME 2.0 development <>
>Miguel de Icaza stated the following:
>> On 30 Mar 2001 09:08:32 -0700, SoloCDM wrote:
>> > When a user is in their account using X, is there a way to keep
>> > them from accessing Settings, System, ...?
>> Well, you could remove the programs that implement those (like removing
>> the control panel package).
>This brings up an interesting point.  If the user is later given an
>administration position, then all those things (like: control panel,
>...) will need to be reinstalled.
>Why not have some configuration file in an administration directory
>simply shut those things off (keep them from loading)?!?!  If I go
>around removing some of these items, some all-in-one package might
>start having a fit if it can't find its dependents.  It doesn't seem
>too much of an out-of-bounds request, because root already has things
>that load into X (in: Red Hat menus) when only root is recognized for
>administration purposes.  If this idea is valid, then why not have all
>workstations controlled by a server.  It would reduce workload and
>increase administration scope from one location.
>gnome-2-0-list mailing list
>gnome-2-0-list gnome org

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