New rule to verify that record modifications has explicit permissions for it

[NAVFreak]

We are going through "permission hell". A customer would like to run permissions which means we have to create roles for all the users and specify access to which objects/tables they should access to.

The problem we are having in our code and ISV:s code is that we and they forget to "declare" permissions for each record that is being modified in an object.

Example:
User A should not have direct access to TableA. A developer creates code in CodenitB which the user as access too. But the developer adds code that modifies data in TableA.
This means that user A runs CodeunitB he will get a run-time error. The only solution to solve it without changing code is if the user is given direct access to the TableA which it shouldn't have!

This is why we need that rule. As soon as the permission is declared in the object we can set so the user has indirect permissions.

Clarification. The rule shouldn't apply to temporary records.
I'm guessing it is hard to track if the record being passed as parameter to a function is temporary or not.

[Arthurvdv]

I understand the possible challenges when working with indirect permissions and having a rule in place for this is a good idea.

Permissions property

Example on Permissions Property

codeunit 50100 MyCodeunit
{
    Permissions = tabledata Customer = rimd;

    procedure MyProcedure()
    var
        Customer: Record Customer;
    begin
        Customer.Insert();
    end;
}

So in this example raise a rule if the Permissions = tabledata Customer = rimd part is missing. How detailed do we need to make this rule? For example if Permissions = tabledata Customer = ri is declared, and we execute a .Delete() statement, the rule should be raised? I then could use some help if there are cases when we also need to verify the 'r' permission?

Inherent Permissions

Example on Permissions Property

codeunit 50100 MyCodeunit
{
    [InherentPermissions(PermissionObjectType::TableData, Database::MyTable, 'i', InherentPermissionsScope::Permissions)]
    procedure MyProcedure()
    var
        MyTable: Record MyTable;
    begin
        MyTable.Insert();
    end;
}

In case of an object within the extension itself, it's also possible to apply the Inherent Permissions attribute on the method itself. So the rule should also consider if this attribute is set and possible combine this with the properties of the object itself to see if there are permissions missing?

I'm guessing it is hard to track if the record being passed as parameter to a function is temporary or not.

You're right at compile-time it's almost impossible to travel the path of the code to try to determine this. And impossible if this is (for example) a public method.

procedure MyProcedure(Customer: Record Customer)
procedure MyProcedure(TempCustomer: Record Customer temporary)

If the method doesn't have the record declared a temporary, then we must assume that non-temporary records are possible and that's why we need the permissions declared?

table 50100 MyTable
{
    TableType = Temporary;

The rule could be excluded when the TableType itself is temporary.

I'm probably missing still a few thing here, where I'm getting the idea this isn't going to be a simple and straightforward rule build. It would be helpful to gather some more insight here, so we can gather more information to have a solid rule which only raises on the right moments.

[NAVFreak]

Some extra context to this:
We use the rule "never add permissions for anything other than TableData" in our permissionsets is taken from these guidelines .

So in this example raise a rule if the Permissions = tabledata Customer = rimd part is missing. How detailed do we need to make this rule? For example if Permissions = tabledata Customer = ri is declared, and we execute a .Delete() statement, the rule should be raised? I then could use some help if there are cases when we also need to verify the 'r' permission?

Initially I would say yes since that would lead to a runtime permission error.

Inherent Permissions

In case of an object within the extension itself, it's also possible to apply the Inherent Permissions attribute on the method itself. So the rule should also consider if this attribute is set and possible combine this with the properties of the object itself to see if there are permissions missing?

I didn't know that this existed 🙈

If the method doesn't have the record declared a temporary, then we must assume that non-temporary records are possible and that's why we need the permissions declared?

Yeah, that assumption must be made.

I'm probably missing still a few thing here, where I'm getting the idea this isn't going to be a simple and straightforward rule build. It would be helpful to gather some more insight here, so we can gather more information to have a solid rule which only raises on the right moments.

I agree. I hope we can get some more experienced permissions coders in this discussion. Currently I'm still new to this and is being the first line support when we or the ISV have forgotten declare the permissions property hence my interest in this rule.

[StefanMaron]

I had the same Idea during a stream yesterday.

Here are my thoughts:

• The rule should not apply when we know its a temp variable
• it should only apply for data access in the current object. Objects down the callstack can have their own permissions set.
• should not apply for objects that are part of inherent permissions
• should not apply for objects that have the property InherentPermissions defined. If the property applies partly, RI for example, then MD should still give warnings.
• Maybe separate rule for tabledata vs other permissions that are just X
• Should probably warn both ways, if few low or to many permissions definded
• AFAIK, the Permissions property exists and works on table, page, report, codeunit, xmlport