On Thursday, August 29, 2019 at 7:27:46 AM UTC-7, Kris Deugau wrote: > > RjOllos wrote: > > > > > > On Wednesday, August 28, 2019 at 5:01:36 AM UTC-7, Klaus Thorn wrote: > > > > 1. I log into Admin-Webfrontend of trac 1.2.3 > > > > 2. Add user to group (under certain permission-conditions that i do > not > > yet understand) > > > > 3. The (better formatted than below) error message appears: > > > > "The subject %(subject)s was not added to the group %(group)s > > because the " > > "group has %(perm)s permission and users cannot grant permissions > > they " > > "don't possess." > > > > In my understanding of English and trac, adding a user to a group > gives > > permissions of the group TO the user. That's my reason to add them, > > anyway. But the error message suggests that the user gives the > > permission (to whom?!). > > > > > > Also confusing: > > > > Via command line, trac DOES add this user to this group, > > and without error. > > > > trac-admin ... permission add user @group > > > > > > You won't see the error if you possess TRAC_ADMIN permission. > > > > If you have PERMISSION_GRANT (1), but not TRAC_ADMIN, then you must be > > granted all of the permissions of the group in order to grant those > > permissions to a user. Otherwise, you could elevate your own privileges, > > or the privileges of others. In the extreme case, you could grant > > yourself TRAC_ADMIN. > > To put it another way, the error is addressing the permissions of the > user trying to make the change, not the user the change is being applied > to. > > When using trac-admin from the command line, you have TRAC_ADMIN more or > less by definition. > > > Example: Suppose group1 has TICKET_ADMIN and you are not a member of > > group1 and do not possess TICKET_ADMIN. Then you cannot add a user to > > group1. If this was allowed, you could elevate your own permissions by > > adding yourself to group1 and granting yourself TICKET_ADMIN. > > > > (1) https://trac.edgewall.org/wiki/TracPermissions#Permissions > > I would argue that the error message should be reworded to something > along the lines of: > > "The subject %(subject)s was not added to the group %(group)s > because the group has permissions that you do not. You cannot grant > permissions you do not possess." > > Listing the permissions you don't have is an information disclosure that > may be a security violation in some environments. >
I'd say that you really shouldn't give PERMISSION_ADMIN to any user you don't trust enough to know the permissions of the environment. Suppose we don't list the permission, and just tell the user that they cannot grant the permission, the user could infer permissions by testing which they are able to grant. - Ryan -- You received this message because you are subscribed to the Google Groups "Trac Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to trac-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/trac-users/0886bf0a-bdb7-4eda-a7a9-9b94324b6974%40googlegroups.com.
