Re: Debian Jr. -- How are we doing?
(Sorry for crossposting to debian-med - but I just want to make sure that
people in this list will be informed ...)
On Fri, 26 Jul 2002, Ben Armstrong wrote:
> 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.
You are right here.
> 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).
I'm not really sure what you mean here. I do not regard a debconf script
as automatical setting. I tried to support the administrator with a tool
to add/remove users to a subproject group.
> 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.
While I think you are perfectly right that we have to differentiate between
security issues and user menus I think both existing projects, junior and med,
do have certain security issues.
Sam provided some reasons for schools where I would be happy to let all
pupils be in a group junior or whatever which is not allowed to use some
certain programs. This would really make sense in my opinion. Moreover
this is a needed feature for Debian-Med. There are applications which are
only allowed for med users. (Think of some confident databases ...)
> 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",
This can perfectly done by the user.
> or even "med" or "junior" user provided that I need no extra
> privileges when I take on that role.
But think of the concept that some applications are only available for
users in the group "med". If any use would be able to add the role med
to his menu stuff some applications are likely to fail. In this case we
would have to ship applications which are able to handle this right via
"You are not allowed ..."
> 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").
In my opinion this leads back to split of the general understanding of a
"role" suggested by me in a former posting in debian-devel back into
"role" and "user level"
While I think that a user should be able to adjust his "user level" himself
I do not think that adding to roles like med or junior is a good idea. This
should not be done without the knowledge of the administrator because
things might break (see above).
More practically I suppose the following approach for {junior,med}-common:
1. continue to manage /etc/groups
2. ask whether /etc/{junior,med}/roles should contain the same users as
in the group {junior,med}
3. in case of "no" in 2. manage a list of users of the role in
/etc/{junior,med}/roles (or any better name for this file) using
debconf
I'm not sure whether the sub projects should care about user levels because
this is a general approach (and if you ask me I'm not really happy about
such stuff).
> 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.
I think this is definitely needed and so I remain managing it - at least
for the Debian-Med.
Kind regards
Andreas.
--
To UNSUBSCRIBE, email to debian-med-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: