Skip to content

BSL247 — Using privileged mode

← All rules

Summary

Using privileged mode

Identifiers

Field Value
Rule code BSL247
Compatible alias SetPrivilegedMode
Severity WARNING
Enabled by default Yes
Implemented Yes
Tags security

Behavior

  • The public identifier BSL247 and alias SetPrivilegedMode are stable.
  • The rule reports the cases documented on this page.
  • Suppressions and project configuration are applied before publication.
  • The rule requires neither an external analyzer nor network access.

Configuration and suppression

BSL### is the primary stable identifier. The compatible alias is accepted in select, ignore, and compatible block suppression comments.

[tool.onec-hbk-bsl]
select = ["BSL247"]
ignore = ["SetPrivilegedMode"]

All three suppression families support both a current line and a range. When an opening comment follows code, it affects only that line. Use any one form:

  • noqa:
Value = "example";  // noqa: BSL247
  • bsl-disable:
Value = "example";  // bsl-disable: BSL247
  • compatible BSLLS form:
Value = "example";  // BSLLS:SetPrivilegedMode-off

When the same opening comment is on a line by itself, it starts a range. Close it with the matching marker from the same family:

// noqa: BSL247
// code without this diagnostic
// noqa-enable: BSL247

// bsl-disable: BSL247
// code without this diagnostic
// bsl-enable: BSL247

// BSLLS:SetPrivilegedMode-off
// code without this diagnostic
// BSLLS:SetPrivilegedMode-on

To disable the rule until the end of the file, omit the closing noqa-enable, bsl-enable, or BSLLS:…-on marker.

Opening and closing markers must belong to the same family.

Description

Diagnostic finds Privileged mode setup code. For external code, such as code from external reports/data processors, this action may not be safe.

The found sections of the code must be analyzed, a manual audit of the code must be performed for its correctness and safety.

Правило находит вызовы метода The diagnostic finds calls to the SetPrivilegedMode method call to SetPrivilegedMode(False) is ignored

Any export procedures and functions that perform any actions on the server with the privileged mode set unconditionally beforehand are potentially dangerous, as this disables checking the access rights of the current user. The export procedures and functions of the client API of the 1C:Enterprise server require special attention.

For example, wrong: 

Procedure ChangeData(...) Export

SetPrivilegedMode(True); // Disable permission check
// Change data in privileged mode
...
EndProcedure
Correct: 
Procedure ChangeData(...) Export

// Changing data
// (at the same time, if the user does not have enough rights to perform an operation on the data, an exception will be raised)
...
EndProcedure
The exception is when the action performed by the procedure must be allowed (or the return value of the function must be available) to absolutely all categories of users.

If you still need to use privileged mode within a method, you must use manual access control using the VerifyAccessRights method.

An example of pre-checking before performing actions in privileged mode: 

Procedure ChangeData(...) Export

VerifyAccessRights(...); // If the user has insufficient rights, an exception will be thrown
SetPrivilegedMode(True); // Disable permission check

// Change data in privileged mode
...
EndProcedure

Examples

    SetPrivilegedMode(True); // error

    Value = True;
    SetPrivilegedMode(Value); // error

    SetPrivilegedMode(False); // no error

Sources