Re: Blocking Access (UPDATE)
- From: Colm Smyth <Colm Smyth Sun COM>
- To: miguel ximian com, deedsmis aculink net, gnome-list gnome org, gnome-2-0-list gnome org
- Cc: gnome-list gnome org, gnome-2-0-list gnome org
- Subject: Re: Blocking Access (UPDATE)
- Date: Fri, 6 Apr 2001 09:56:03 +0100 (BST)
Hi,
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
Colm.
>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 <gnome-2-0-list.gnome.org>
>
>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.
>
>*********************************************************************
>Signed,
>SoloCDM
>
>_______________________________________________
>gnome-2-0-list mailing list
>gnome-2-0-list gnome org
>http://mail.gnome.org/mailman/listinfo/gnome-2-0-list
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]