[rt-users] putting unprivilged users in local groups

[Jesse Vincent]

Hm.  So, I hadn't really thought much about the concept of non-privileged
users being group members.  It wasn't something I'd really considered. But 
you make a good argument for it.  I don't _think_ there's anything in
the code that would really flip out if the UI were changed to allow adding
non-privileged users to groups.	


	



On Mon, Sep 24, 2001 at 03:54:39PM +1000, Cris Bailiff wrote:
> Hi,
> 	I have what I think would be a common requirement, but I can't see the
> obvious way to implement it in rt2, except by exploiting a pseudo-bug I
> found..
> 
> * I want my unprivilged users to be able to use the web interface to see
> their tickets and enter new tickets
> * I don't want these users to see all the queues we have, only the ones
> that they are authorised for (for some definition of 'authorised').
> 
> * Using the web interface, an unprivilged user can see the 'New Ticket'
> page and that page has the appropriate drop down box for 'Queue'
> selection.
> * The box is correctly populated with only the queues that a given user
> has 'SeeQueue' privilege for.
> 
> Now the problem:
> * Unpriviliged users can only be given 'SeeQueue' by granting the priv
> to the 'Everyone' Pseudo-group, as they are not members of any other
> group.
> * If I grant see-queue to 'Everyone', then unpriv-user-a can see queueus
> that should only be seen by unpriv-user-b and vice-versa.
> 
> I can create a group of users with 'SeeQueue' only for a particular
> queue or set of queues, but I can't put an unprivilged user into that
> group, because only priv'd users are allowed to be in  groups (at least,
> the web GUI only offers that option), so I can't grant an unpriv-user
> limited 'SeeQueue' privs by putting them in groups.
> 
> * I 'worked around' this in a slightly odd way - I made the unpriv user
> privilged, then put them in the appropriate local group(s), then removed
> the 'privilged' flag again.
> * This didn't remove the user from the groups, and the group memberships
> remained active when the user used the web GUI - they could now select
> from the limited list of queues...
> 
> This is what I wanted, but I didn't like granting the user priv status
> (even temporarily), as this is bound to go wrong (human factors etc.) at
> some point and be embarrassing.
> 
> Where is the problem here? Is it just the 'group membership' GUI thats
> deficient? Why can't I put unpriv'd users into groups and grant them
> certain privs?  Should I be able to do that without ticking the 'Allow
> this user to be granted rights' box?
> 
> The option to allow the user to 'be granted rights' seems to be very
> generous - users can search and enumerate other users, see ticket &
> queue stats etc. etc., which is much more than unprived users should
> have (obviously), but it seems I can't be selective with privs unless I
> grant the user these extra rights (which I can't take away again).
> 
> Anyone have any suggestsions for a better approach, or a fix? Is this a
> design decision that's hard coded, or just a minor mis-feature?
> 
> Cheers,
> Cris Bailiff
> c.bailiff+rt2 at devsecure.com
> 
> _______________________________________________
> rt-users mailing list
> rt-users at lists.fsck.com
> http://lists.fsck.com/mailman/listinfo/rt-users
> 

-- 
http://www.bestpractical.com/products/rt  -- Trouble Ticketing. Free.