Potential security breach on constructs which NQ has said is as intended!!

[blazemonger]

 

Setting:

An org which has an industry complex where org members can use all industry freely. The way it is set up is that they can use an INPUT container to put their materials in (but not take anything out) and the industry will then deliver to the OUTPUT container from which they can collect (but not put anything in).

 

Affected rights:

1. Use Element - Gives the right to use an element
2. Put Items in container - Gives the right to put items in a container
3. Retrieve items from container - Gives the right to retrieve items from a container 
4. View container contents - Gives the right to view a container's content

 

Expected:

As 2-4 are very specific rights for containers (2 and 3 would obviously also include the right to view contents) it would be logical to understand that containers are treated differently from elements in general with regards to access

 

Actions:

91)  applied to the construct allowing members to use all industry elements on the construct.
(2) applied to the INPUT container.

(3) applied to the OUTPUT container.

 

Observed behaviour:

All containers on the construct are fully accessible to anyone in the Actor for whom the "use Elemen"t is set on the construct.

 

Expected behavior:

Anyone in the Actor for whom (1) is set on the construct can use all elements except containers

The container(s) which have (2) set can only be viewed and have items put in to 

The. container(s) which have (2) set can only be viewed and have items taken out of

 

 

NQ says that the observed behaviour is as intended but I must question this because of the messages seen when you work around this issue by not setting a construct wide "Use Element" but apply it to every element on the construct which should be accessible separately, which as you may understand can be a royal PITA on a big multipurpose industry complex

 

Since NQ has declared this as intended and not a bug I feel it's fine for me to post on this here.

 

As the "as intended" behaviour forces you to set individual rights to each element separately it will in fact trigger an error as the "use element" right is not applied as permitted action on the relevant containers:

 

 

IMO this should show this is not intended behaviour at all but an oversight where "Use Elements" should not apply to containers at all. It is clear from this image these rights conflict.

 

This was something I discovered "by accident" and nothing was actually stolen. It is easily (and quickly) fixed by removing the dependency on the "use element" right from containers.

 

 

[GraXXoR]

So you’re saying that if you have a construct with no use elements rights and then assign only put in or take out rights to the element, it doesn’t work?

 

what about if you have a construct with use elements rights, but then on the containers remove parent inheritance on RDMS and just add deposit items or retrieve items locally?

 

 

also, 2 does not “obviously” include the right to see container content. At least it wouldn’t in a Windows or Linux ACL. 

[joaocordeiro]

Well NQ is right.

Rules never take out any permission, only give new ones. 

The construct level "use" adds input and output rights on all elements. 

Then "put" is not doing anything there. 

 

What you say you would expect would happen if "put" permission had a "not take" directive. But thats not how the system is designed. 

 

Never ever give "use" on construct level. 

 

The alternative is to make a composite tag that only affects some element types and give "use" on construct level to that tag. That way you can set construct level "use" just for industries and not for containers. 

[blazemonger]

I do not agree their position is correct. If NQ is right, there should not be an error seen when I correctly set up rights for containers to only allow input or output.

 

Also having to set "Use element" on each of hundreds (potential) elements on a construct kind of goes against the idea of having a central rights option. 

If the "Use Element" tag would not apply to containers (as they have their own specific rights regarding access) this issue goes away instantly.

 

For a construct open to your org where members are free to use industry, setting "Use Element" on the construct makes sense when containers are not included in that right. and would allow use of any of the elements on the construct besides containers which then have their own rights set as needed. This is far more efficient and flexible.

 

 

@GraXXoR

It works but it also throws an error because the "Use element" right is not set. This in itself shows that these tights cause a conflict. If this was intended behavior, then once I set either Pt, Retrieve or View rights on a container, whether or not Use element is set should not be relevant and not throw an error.