Permission checks

[Ray Augé, geändert vor 15 Jahren.]

Ownership permissions....

Currently when a User creates a new model object, they are granted all
the model resource actions defined for that model resource type.

Next, when a permission check occurs... first we do all kinds of
checking of administrative rights, on and on, until in the final check
we do... "oh look! you DO have all privileges on this model object;
return true".

Now the benefit is of course that we can remove some of those default
granted permissions so that this final check fails.

So, say you wanted to remove "UPDATE" from a "specific" Message Board
post from its original owner, you could technically do that...... :|

That being said, my question is... does anyone really do this? I mean is
there a lot of cases where an admin will find a specific model object
and remove a given permission from its original owner?

I'm asking because it would be VERY much faster (from my tests at least
500% faster, no DB call required) to simply check if the model object is
owned by the current user and, if so, return true, if not continue with
the normal checks.

OR, even better (so that we retain flexibility), rather than simply
returning true, check the current action against some default list of
"owner" model resource actions that can be configured (possibly at rune
time (a.k.a. an ACL)). Difference here is that it would apply to all
users...

So, again, to make the question really clear:

Do we often modify the individual permissions granted to the OWNER of
a distinct model object (which by default is all permissions)?

Let me know if the question is still not clear.


Raymond Augé
Software Engineer
Liferay, Inc.
Enterprise. Open Source. For Life.

[Michael Young, geändert vor 15 Jahren.]

The only thing I can think of is if the owner wanted to keep himself from doing something stupid, like deleting an important object.

[Wilson Man, geändert vor 15 Jahren.]

i suppose there might be a time when you want the resources contributed by users to be final and not alterable. let's say a forum where people can't modify their posts to manipulate ...

[Arcko Duan, geändert vor 15 Jahren.]

Not often.

[Ray Augé, geändert vor 15 Jahren.]

Ok, so it's pretty obvious that there isn't a great outcry of support
for this...

While I'm not proposing to eliminate the feature altogether... I'd like
to entertain introducing a configuration option which short-circuits the
permission checks by simply doing an ownership check on the object
itself.

Here is an experimental code fragment from my BookmarksEntryPermission:

	public static boolean contains(
		PermissionChecker permissionChecker, BookmarksEntry entry,
		String actionId) {

		if (isOwner(permissionChecker, entry)) {
			return true;
		}

		BookmarksFolder folder = entry.getFolder();

		return permissionChecker.hasPermission(
			folder.getGroupId(), BookmarksEntry.class.getName(),
			entry.getEntryId(), actionId);
	}

	public static boolean isOwner(
			PermissionChecker permissionChecker, BookmarksEntry entry) {

		if (PermissionCheckerImpl.USER_CHECK_OWNERSHIP &&
				permissionChecker.getUserId() == entry.getUserId()) {
			return true;
		}

		return false;
	}

A property might exist for
[tt]PermissionCheckerImpl.USER_CHECK_OWNERSHIP[/tt], like

    #
    # Set this to true when you want to grant permanent and unrestricted
    # ownership of an entity to its creator. This speeds up permission
checks
    # considerably, especially with extensive use of Private
Communities.
    #
    permissions.user.check.ownership=false

So, while this may not seem like a lot, it actually is quite a lot when
compounded for all users in a system. In particular, where the system is
intensely user-centric (like where users own much of the content, a.k.a.
Private Community, Blogs, Message Boards, etc..). There are at least a
half dozen queries which are eliminated from the equation on each check
(though to be fair, those might be cached... but none the less).

Note that this only works on entities which are "owned" by a user, as
not all entities have a userId field. But there are a significant number
that ARE owned (80+%).

[Joel Kozikowski, geändert vor 15 Jahren.]

Ray Augé:

		if (isOwner(permissionChecker, entry)) {
			return true;
		}

I'm not so sure I like this idea. This sounds way too much like the "user's who have MANAGE_LAYOUT privileges are Super Users" problem we discussed on that other thread.

Here is one use case that may cause problems: My use case is I have an ASP like environemnt, where each "location" is a customer. I create a "Location administrator" who can do a variety of things, including adding new users to their own location. While I want that user to be able to perhaps edit the user they created, I don't want this location administrator to be able to adjust the permissions of that user, assign roles, or delegate permissions to them. The permission system in MY application is locked down and administered by the omni-admin, as well as custom code.

So, without looking TOO closely at the code fragment you cited, would your proposal suddenly grant omni-admin like functionality to my "location admin" on any users he created?

I can see this making sense for "lesser" entities like "Bookmarks", but NOT for "critical" entities, like "Users", "Organizations", etc.

[Ray Augé, geändert vor 15 Jahren.]

These are very good arguments, kinda what I was looking for... and yet
the [tt]isOwner()[/tt] doesn't really apply to any objects which make up
the enterprise/autorization/scoping stack.

For example, Group, Org, Location, User, etc... don't have a
[tt]userId[/tt] fields in the first place.

That's kinda why I limited to the question to owned model
objects.

In fact, the code I have in place actually looks like this:

	public static boolean contains(
		PermissionChecker permissionChecker, BookmarksEntry entry,
		String actionId) {

		if (isOwner(permissionChecker, entry)) {
			return true;
		}

		BookmarksFolder folder = entry.getFolder();

		return permissionChecker.hasPermission(
			folder.getGroupId(), BookmarksEntry.class.getName(),
			entry.getEntryId(), actionId);
	}

	public static boolean isOwner(
			PermissionChecker permissionChecker, BookmarksEntry entry) {

		if (PermissionCheckerImpl.USER_CHECK_OWNERSHIP &&
				permissionChecker.getUserId() == entry.getUserId()) {
			return true;
		}

		return false;
	}

where [tt]PermissionCheckerImpl.USER_CHECK_OWNERSHIP[/tt] is a config
option to disable the behavior.

So, again... this is for owned model objects... like
BookmarksEntry, and not like User, or Organization, or Role, etc...

The entire purpose here is to eliminate a myriad of further checks when
the user IS the owner...

Does that make more sense, or is it still too much of a restriction?

I was even thinking that it might be better to have something like an
"owner" ACL which could possibly be set at runtime (but defaults to a
config, like resource actions for "owners"):

	public static boolean isOwner(
			PermissionChecker permissionChecker, BookmarksEntry entry, String
actionId) {

		if (PermissionCheckerImpl.USER_CHECK_OWNERSHIP &&
				permissionChecker.getUserId() == entry.getUserId()) {
			return getOwnershipACL(BookmarksEntry.class.getName(),
entry.getEntryId(), entry.getGroupId(), actionId);
		}

		return false;
	}

where [tt]public static boolean getOwnershipACL(String className, long
classPK, long groupId, String actionId);[/tt] checks the currently
defined ACL.. notice it could potentially be scoped by group...

[Julio Camarero, geändert vor 15 Jahren.]

Hi Ray!

I was wondering what is the current situation of this "Permission checks"...

I can't see this permissions.user.check.ownership property anywhere and in the last version permissions system, the owner of an object (a post in a message board, for example) is not allowed to edit or delete it.
Are you working on that?

I have some users asking for it in the Spanish forums,

Thank you!

[Ray Augé, geändert vor 15 Jahren.]

On Thu, 2008-09-04 at 09:29 +0000, Julio Camarero at Liferay's Community
Forums wrote:

> I can't see this permissions.user.check.ownership property anywhere
> and in the last version permissions system


We never implemented that part of the permission check changes... but I'm still debating this with our team.

Personally, I still think it is needed.

[Julio Camarero, geändert vor 15 Jahren.]

I agree with you.

Users need love to be able to edit their own messages at forums... (at least before somebody answers to their messages)


Cheers!