Re: Debian Jr. -- How are we doing?
On Thu, Jul 25, 2002 at 08:44:40AM +0200, Andreas Tille wrote:
> On Sun, 21 Jul 2002, Andrew Pimlott wrote:
>
> > Please don't conflate a configuration mechanism (which users see
> > which menus) with access control (unix groups). It is confusing,
> > provides no benefits, and wastes the limited number of groups to
> > which a user can belong.
> The benefit of using unix groups is that there is a defined set of tools
> provided to handle user groups. This makes life much easier. Moreover
> I do not know any *practical* limit of the number of groups which a user
> can belong.
I'm becoming more of the opinion that we're trying to solve two problems at
once here, and that we should therefore carefully divide the two problems
and define the interaction between.
The first is to provide the admin with a way to enforce in their security
policy access to a certain pool of resources with the group. The precedent
in Debian is "games". However, adding members to the "games" group has
always been the responsibility of the admin. I'm not sure we should have a
config script do that automatically. Or if we do, we at least need to give
the admin the option of not taking advantage of the group admin feature of
the config script (and likely establish this as the default).
The second issue is to provide a common set of menus for all members of the
group. This is not a security issue. Some subprojects will have no need
at all for a Unix group for security purposes and therefore a Unix group
makes no sense for them.
There is also a problem with using Unix groups to implement subproject user
groups, and that is that admin intervention is required to set up a user.
This is appropriate when there are security issues connected with group
membership but is inappropriate when just selecting a user level (or as
discussed elsewhere, a "role") that has no security implications. I should
be able, myself, to decide whether I am a "novice", "intermediate",
"expert", or even "med" or "junior" user provided that I need no extra
privileges when I take on that role.
Therefore I propose that we change the model immediately. Perhaps there
should be a $HOME/.menu/roles for each user. All that would be needed then
is a way for each user to update their own menus based on the roles listed
there (bonus points if this can be done each time the WindowManger starts or
does a "restart").
As for the security group thing, that's a nice idea, but I have yet to find
a real use for a "junior" group at this time other than menus, so the idea
should be shelved until such time as the group is really needed.
> Moreover it might happen that we completely rethink because of the upcoming
> new menu system which (hopefully soon) implements some roles mechanism
> which is in fact better than our first attempt.
Probably.
Ben
--
nSLUG http://www.nslug.ns.ca synrg@sanctuary.nslug.ns.ca
Debian http://www.debian.org synrg@debian.org
[ pgp key fingerprint = 7F DA 09 4B BA 2C 0D E0 1B B1 31 ED C6 A9 39 4F ]
[ gpg key fingerprint = 395C F3A4 35D3 D247 1387 2D9E 5A94 F3CA 0B27 13C8 ]
--
To UNSUBSCRIBE, email to debian-jr-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: