Prioritizing access from a container instance to a file in a file system resource

Description

[0001] The invention relates to methods for prioritizing access from a container instance to a file in a file system resource.

[0002] Container virtualization is a method in which multiple instances of an operating system can use an operating system kernel on a guest computer in isolation from one another. Software containers, or containers for short, represent a lightweight way of virtualizing a runtime environment on a guest computer, also called a host system, and encapsulate a software application running in a container from the underlying host system. Software applications, or the services provided by software applications, are now being implemented using containers in many areas, such as industrial automation and process control, but also for applications in transport systems or vehicles.

[0003] To start a container on the host system, a container image is required. This image contains not only the application software but also the binaries and libraries required for the application software. A container, or more precisely a container instance, is created from the container image on the host system and executed in the runtime environment. If necessary, for example, if the application is accessed frequently by users, additional container instances can be created and executed from the same container image on the same or a different host system.

[0004] Traditionally, container instances are run using a container runtime environment such as Docker in the host system's operating system, which may also be configured as virtualized hardware resources. Files or file system areas on a storage resource provided by the host system, which the container instance or a process running within the container instance wishes to access, are assigned to the container instance, for example, at startup, and access permissions to these files are assigned.

[0005] The host system's operating system controls which processes have access to the file based on the access permissions assigned to the file. Multiple container instances of the same container image can run in parallel on a host system and also access the file assigned to the respective container instance in parallel. Container instances of different container images can also use the same file. In both cases, it is often necessary to serialize write access to the file. Once write operations to the file are performed, it must be ensured that a writing process performs the access exclusively for the desired period of time.

[0006] CN 112 580 086 A describes an access protection method for a configuration file. The access method is executed in isolation by an application in a container. To avoid conflicts between multiple write requests to the configuration file, the write requests are placed in the request queue according to a predetermined queuing mechanism, for example, in the order in which the write request was received or according to the priority of the write request. The request parameters from each write request in the queue are then written sequentially to the configuration file.

[0007] SIEMENS AG CHRISTIAN KNIERIM DE-MUNICH ET 1-15 AL: "Definition and Verification of Complexity Rules for Confidential Information in Container Instances", PRIOR ART PUBLISHING GMBH, PRIOR ART PUBLISHING GMBH, MANFRED-VON-RICHTHOFEN-STR. 9, 12101 BERLIN GERMANY, vol. www.priorartregister.com, July 15, 2021 (2021-07-15), pages 1-5, XP007024163, describes a method for verifying complexity requirements or complexity rules for confidential information that automatically detects the criticality of a runtime parameter and performs complexity checks based on this detection.

[0008] US 2020 / 326984 A1 discloses a Docker container-oriented method for isolating file system resources. The method uses isolation-related lock contention in shared operating system kernels and file system resource contention, which allocates guest file system resources according to container access requests and checks lock resources according to the access requests.

[0009] There is therefore a need for a solution that ensures that the write resource usage of a device file is serialized for individual instances or container images and is restricted, delayed, or prioritized depending on their trust level or properties. In the worst case, if a container instance blocks a device file for longer than the permitted duration or accesses it continuously, it should also be ensured that such an instance is terminated.

[0010] It is therefore an object of the present invention to provide a method that ensures that the write resource usage of a file is serialized for individual container instances or container images and is restricted, delayed or prioritized depending on their properties.

[0011] This object is achieved by the measures described in the independent claims. Advantageous further developments of the invention are presented in the subclaims.

[0012] According to a first aspect, the invention relates to a method for prioritizing access from a container instance to a file in a file system resource, comprising Receiving, in a runtime environment of the container instance, an access request for access from the container instance to the file, wherein the access request contains an access identifier that identifies at least one property of the accessing container instance, checking the at least one property in the access identifier against an access policy that includes a prioritization level for access to at least the one file depending on the properties of the access identifier, by an access control unit in the container runtime environment, and assigning an access authorization with a prioritization level to the access request depending on the verification result, forwarding the access request to the file depending on the assigned prioritization level.

[0013] This allows specific access permissions to the file to be set and enforced for the container instance. The access identifier can be implemented as a label, i.e., a jump label. The properties in the access identifier can be stored in a memory area marked with the jump label and made available for review. The access policy can be used to link prioritization levels, which specify a processing order for accessing the file, to the properties of the container instance. This allows for flexible assignment and enforcement of access permissions.

[0014] In an advantageous embodiment, the file is a device file that receives control commands from the container instance and forwards them to a hardware resource controllable by the container instance for execution.

[0015] The hardware resource is assigned to the container instance through a configuration file when the container instance is started. The hardware resource is also referred to as a device. As soon as processes in the container instance want to transmit control commands to a device, the container instance passes the control commands to the device file created on the file system. The device file forwards the control commands to a controller, which translates them into device-specific control commands. Thus, the container instance's access identifier in the access request can be used to provide prioritized access to the device specifically for the container instance.

[0016] In an advantageous embodiment, the access identifier is created specifically for the container instance. Alternatively, the access identifier is created specifically for the container image, and the container image-specific access identifier is assigned to each container instance created from the container image.

[0017] This allows access permission prioritization to be set up specifically for each container instance. If the access identifier is created specifically for a container image, the same access permissions can be easily defined and enforced for all container instances created from the container image.

[0018] In an advantageous embodiment, the prioritization levels for the access of the accessing container instance to the hardware resource are specified by an operator of the hardware resource.

[0019] This allows the operator of the hardware resource or the associated device, which is not necessarily an integral part of the host system, to influence container instances accessing permitted access rights.

[0020] In an advantageous embodiment, a property in the access identifier is at least one of a selection of: a name of the access identifier, a signature of the accessing container instance, a signature of the container image from which the accessing container instance is created, and / or a name of the container image.

[0021] A degree of trust can be derived from the signature of the container instance or container image. Each property in the selection can be assigned a priority level for access permissions to the file or device file via the access policy. This allows access permissions to be flexibly linked to different properties.

[0022] In an advantageous embodiment, at least one network interface is assigned to the container instance, and the access identifier contains an identifier for each of the at least one assigned network interfaces.

[0023] This allows prioritized access authorization depending on the container instance's affiliation to a network interface.

[0024] In an advantageous embodiment, the identifier of the associated network interface is assigned to the network interface by an operator of the container runtime environment.

[0025] This allows the container runtime operator to control access from a container instance to the network interface.

[0026] In an advantageous embodiment, the access policy comprises a prioritization level for each of the identifiers of the network interfaces.

[0027] This allows the prioritization level of access authorization to be set up in fine-grained detail depending on each individual network interface.

[0028] In an advantageous embodiment, the prioritization level associated with the first property contained in the access identifier in the access policy is assigned to the access request.

[0029] For example, if multiple network interfaces are assigned to a single container instance, the priority level for accessing the device file is determined by the network interface listed first in the access identifier. Thus, the priority level for accessing the device file can be determined by a specific order of the properties in the access identifier.

[0030] In an advantageous embodiment, the highest priority level from all priority levels associated with the properties contained in the access identifier is assigned to the access request.

[0031] This allows an alternative interpretation of the access identifier.

[0032] In an advantageous embodiment, the access policy for each of the at least one file comprises a name of the file and at least one property from a selection of the following properties: a name of the access identifier, a signature of the accessing container instance, a signature of the container image from which the accessing container instance is created, a name of the container image or an identifier for a network interface, and at least one of the properties from the selection is assigned a prioritization level.

[0033] The properties are assigned a prioritization level in the access policy. If the identifier of a network interface of the container instance is assigned a high priority level, the access request is given preferential treatment compared to an access request from a container instance whose network interface is assigned a low priority level.

[0034] In an advantageous embodiment, the access policy for each of the at least one file comprises at least one item of information from a selection of: a process name for a process requested via the access request, an access mode, a maximum access duration, preferably depending on the properties of the access identifier.

[0035] The access policy can therefore specify the access mode for each file, i.e., whether the hardware resource can be accessed in parallel write mode or exclusively, i.e., serially. If parallel write access is permitted, a maximum number of parallel write operations can be defined. The access mode specifies, for example, whether parallel access is permitted only by container instances of the same container image or by container instances of different container images.

[0036] In an advantageous embodiment, the access control unit is designed as an extension module in the container runtime environment or as a standalone unit separate from the container runtime.

[0037] By implementing the access control unit as an extension module, the prioritization of access permissions can be performed quickly on the host system. By implementing the access control unit as a standalone unit, the process is better isolated from the container runtime environment and can also be integrated into other parallel runtime environments. Alternatively, the access control unit can be distributed across all systems managed by the orchestrator via a central deployment system, for example, using an orchestrator.

[0038] A second aspect of the invention relates to a device for prioritizing access from a container instance to a file in a file system resource, comprising a runtime environment of a container instance configured in such a way to receive an access request for access from the container instance to the file, wherein the access request contains an access identifier that identifies at least one property of the accessing container instance, to check the at least one property in the access identifier against an access policy that includes a prioritization level for access to at least the one file depending on the properties of the access identifier, by an access control unit in the container runtime environment, and to assign an access authorization with the prioritization level to the access request depending on the verification result, and to forward the access request to the file depending on the assigned prioritization level.

[0039] The device according to the invention allows several container instances to access the same file simultaneously and to be prioritized.

[0040] A third aspect of the invention relates to a computer program product comprising a non-transitory computer-readable medium that is directly loadable into a memory of a digital computer, comprising program code parts that, when executed by the digital computer, cause the digital computer to carry out the steps of the method.

[0041] Unless otherwise stated in the following description, the terms "receive," "verify," "assign," "forward," and the like preferably refer to actions and / or processes and / or processing steps that modify and / or generate data and / or convert the data into other data, wherein the data can be represented or present in particular as physical quantities, for example, as electrical impulses. The device and the runtime environment contained therein can comprise one or more processors.

[0042] A computer program product, such as a computer program means, can be provided or delivered, for example, as a storage medium, such as a memory card, USB stick, CD-ROM, DVD, or in the form of a downloadable file from a server in a network. This can be done, for example, in a wireless communications network by transferring a corresponding file to the computer program product or the computer program means.

[0043] Embodiments of the method and device according to the invention are illustrated by way of example in the drawings and are explained in more detail in the following description. They show: Fig. 1 shows a schematic representation of an embodiment of the system according to the invention designed as a host system with a runtime environment; Fig. 2 shows an embodiment of the method according to the invention as a flowchart; Fig. 3 shows a schematic representation of an embodiment of an access identifier according to the invention; and Fig. 4 shows a schematic representation of an embodiment of the access policy according to the invention.

[0044] Corresponding parts are provided with the same reference numerals in all figures.

[0045] Based on Figure 1 the individual components of the system according to the invention and an interaction between container instance and access to a file assigned to the container instance are shown.

[0046] Figure 1shows a system 10 comprising hardware resources 11, an operating system with a container runtime environment 12, and two container instances 13, 14 running on the container runtime environment 12. Hardware resources 11 are, for example, a control unit 15, a storage unit 16, or a network interface 18 physically implemented in the system. The network interface can also be implemented as a virtual network interface. Both the physical and the virtual network interfaces are addressed via the operating system kernel 22. A file 17 is stored in a file system in the storage unit 16. The file 17 is assigned to the container instance 13 and is thus accessible by integrating the file 17 into a mount namespace of the container instance 13, also called a "mount namespace," using a "bind-mount" command, for example, or by sharing another mount namespace that contains the file 17.

[0047] If the container instance 13 or a process running on the instance wants to access a file 17, the operating system or the container runtime environment 12 controls which processes have access to the file based on access permissions.

[0048] If multiple container instances of the same container image are running in parallel on a host system, these container instances typically access the file assigned to each container instance in parallel. This is especially the case when orchestration solutions like Kubernetes detect an overload situation for existing container instances and scale them up, i.e., create and start additional container instances from the same container image. If too many container instances are started, the scaling-up may result in too many accesses to the file being transferred, and these accesses are no longer processed correctly.

[0049] Container instances of different container images can also use the same file and perform different tasks on the same controller. These container images can also be provided by different vendors and do not always have the same level of confidentiality.If the file 17 is a device file that receives control commands from the container instance 13 and forwards them to a hardware resource 11 controllable by the container instance 13, for example the control unit 15, for execution, then in a conventional system a malicious container instance can, by permanently writing to the device file, place a load on a control unit 15 connected to the device file in such a way that, for example, control signals from other container instances relevant to operational safety can no longer be sent and thus the security of the host system or a system in which the container instance is operated via a cloud-based host system is endangered.

[0050] In both cases, it is also often necessary for write accesses to the file to be serialized, i.e. that write operations are performed one after the other and not simultaneously.

[0051] A basic idea is that container instances 13, 14 have certain properties, and access to a file 17 is prioritized depending on one or more of these properties.

[0052] The method according to the invention for prioritizing access from a container instance, for example container instance 13, to a file, for example file 17, in a file system resource, for example storage unit 16, is described in Fig. 2 shown.

[0053] In a first method step S1, the runtime environment 12 of the container instance 13 receives an access request R1 for access from the container instance 13 to the file 17. The access request contains an access identifier L1 that specifies at least one property of the accessing container instance 13. The file 17 can be any type of file, but in particular can also be a device file. The access identifier L1 is created specifically for the container instance 13, so that each container instance 13 is assigned its own, for example, unique access identifier L1. The access identifier L1 can also be created specifically for the container image, so that each container instance created from the same container image is assigned the same container image-specific access identifier.

[0054] In the next method step S2, at least one property in the access identifier L1 is checked against an access policy 20, AR, and a prioritization level for access to the file 17 is determined by an access control unit 19 in the container runtime environment 12 based on the properties of the access identifier L1 using the access policy 20, AR. Subsequently, the access request R1 is assigned an access authorization with the prioritization level AP resulting from the check (see method step S3). The access request R1 is placed in a queue 21, for example, according to the prioritization level AP for transfer to the file 17. The access request R1 is then forwarded to the file 17 depending on the assigned prioritization level AP.

[0055] If the file 17 is a device file, the prioritization level AP for access to the hardware resource addressable by the device file, for example the control unit 15, can be specified by an operator of the hardware resource, thus the manufacturer of the control unit 15.

[0056] The access control unit 19 is configured as an extension module of the container runtime environment 12 in the system 10 or as a standalone unit separate from the container runtime. The system 10 with the runtime environment 12 is configured to execute the described method.

[0057] In Fig. 3An exemplary embodiment of the access identifier L1 is shown. The access identifier L1 of the container instance 13 comprises at least one of the properties of the container instance 13. Properties can be, in particular, a name LN1 of the access identifier L1, a signature S1 of the container instance 13, a signature SI1 of the container image from which the accessing container instance 13 is generated, or a name O1 of the container image. If one or more network interfaces are assigned to the container instance 13, the access identifier can comprise an identifier NW1 for each of the assigned network interfaces. The identifier NW1 is preferably assigned to the network interface by an operator of the container runtime environment 12.

[0058] Fig. 4shows an embodiment of an access policy 30, AR. The access policy 30, AR comprises, for each of the at least one file 17, a name DN1, DN2 of the respective file and at least one property of the container instances authorized to access it. Furthermore, the access policy comprises at least one prioritization level Prio1, Prio2. The at least one prioritization level Prio1, Prio2 is assigned properties corresponding to the properties contained in the access identifiers. The properties contained in the access identifier L1 are thus checked against the properties in the access policy 30, AR. The prioritization level Prio1, Prio2 that is assigned to the first property contained in the access identifier is assigned to the access request.In this approach, also known as the first-hit approach, the priority level Prio1 or Prio2 is used for a file for which write access is to be regulated, which matches the first property in the container instance's access identifier. Alternatively, the highest priority level can be assigned to the access request across all properties specified in the access identifier.

[0059] Figure 4shows a selection of possible properties in the access policy are: a name LN1 of the access identifier L1, a signature S1 of the accessing container instance 13, a signature of the container image SI1 from which the accessing container instance is created, a name O1 of the container image or an identifier NW1 for a network interface. Each property is assigned to a prioritization level. The access policy 20, AR comprises for each of the at least one file 17 preferably further comprises at least one piece of information from: a process name for a process P3, P4 of the container instance requested via the access request, an access mode, a maximum access duration, preferably dependent on the properties of the access identifier or dependent on the respective process. It can be specified for each file 17 whether it may be accessed in parallel write or exclusively write.If parallel write access is permitted, a maximum number of parallel write actions can be defined.

[0060] The network interface identifier NW1 allows access to file 17 to be prioritized based on the container instance's affiliation with a network interface, also known as a network bridge. Network interfaces allow container instances to be segmented on the network side. Access policies 20, 30, and AR can thus ensure that container instances operating in a more critical data network can be given higher priority.

[0061] If a container instance is connected to multiple network interfaces, the access policy 20, 30, AR must also define whether the rules of the network interface with the lowest priority level or the rules of the network interface with the highest priority level are used. For this purpose, the network interfaces must be prioritized accordingly when created by an operator of a hardware resource accessed via the network interface or by a configurator of the application running in the container instance. This is possible by defining the priority of the access identifiers, or the properties within the access policy, and / or the order of the properties in the access identifier.

[0062] The same applies to container instances or container images whose access identifier contains multiple properties of the same type, for example, multiple signatures.

[0063] The access policy 20, AR is controlled by an access control unit 19, see Fig. 1 , which is implemented as an extension of the container runtime environment 12 or as a standalone component. The access control unit 19 is configured to automatically create a monitoring program based on the access policy 20, 30 upon an access request R1 from a process of the container instance 13 to the file 17. This monitoring program generates an alarm, for example, via an extended Berkeley Packet Filter (eBPF) interface of an operating system kernel 22 and transmits it to the monitoring component in the access control unit 19. The process is first temporarily interrupted and suspended, in other words, put to sleep, using an eBPF program.

[0064] The access control unit 19 first checks whether the process belongs to a container instance for which access has been granted. To determine whether a process belongs to the container instance 13, the access control unit 19 can either interact with the container runtime environment 12 via a communication interface, for example, a Docker socket. Alternatively, the access control unit 19 can register process namespaces started in the container runtime environment 12 and monitor other processes started in this process namespace, for example, using eBPF programs.

[0065] Upon receipt of an access request to the file 17 or upon starting the container instance 13, the access control unit 19 determines further information such as identifiers belonging to a network interface, a container image or a container instance. The access control unit 19 queries this information from the container runtime environment 12, for example via the Docker socket or corresponding programming interfaces. The access control unit 19 also determines to which interfaces a network interface 18 assigned to the container instance 13 is connected. This is determined in advance when network interfaces are added and removed. If the relevant properties such as the container image name or signature are determined before accessing the file 17, for example upon start-up and when changes ora stop of the container instance 13, the parameters stored in the access policy 20 are temporarily stored for each container instance in the access control unit 19.

[0066] The determination of the signature information of the container image belonging to a container instance 13 is carried out either directly via the access control unit 19 by directly accessing the cached images and the signature data of the container runtime environment 12 and performing this check itself, or by reading the corresponding information from the container runtime environment 12 via corresponding interface commands and trusting that the container runtime environment can perform a correct check.

[0067] If file 17 is exclusively usable or the maximum number of parallel writing processes is not reached, the access control unit 19 informs the operating system, in particular an operating system kernel 22, via the eBPF interface that the process it has put to sleep may be executed. As soon as the process terminates write access to file 17, the access control unit 19 is also informed by the operating system kernel 22 using defined eBPF programs.

[0068] The maximum access duration for a container instance 13 can be defined either globally for the file 17 or for each property in the access identifier. The access control unit 19 monitors the maximum access duration stored in the access policy 20. If the respective maximum access duration is exceeded, access can remain permitted as long as there are no further access requests for the file. If the access request is for a device file, longer access can be permitted if there are no further resource requests for the hardware resource addressed by the device file. If there are further access requests for the file 17, the access control unit 19 can inform the associated container instance 13 to release access immediately and / or directly terminate the process that is using the device file beyond the permitted time period.This can be done, for example, with the help of appropriate interprocess communication mechanisms in the operating system.

[0069] If parallel write access to the device file is possible, the process can simply be put to sleep again instead of terminating it. This is possible because it is assumed that when file 17 is used in parallel, no serialization of accesses needs to be performed, but rather only higher-priority container instances, for example container instance 14, need be given priority access to the file. If file 17 is occupied and a new process wishes to access it, access control unit 19 checks its priority and assigns it to a process queue 21 created for its priority. Process queue 21 is processed according to its priority via process scheduling in kernel 22. As soon as access to file 17 is possible, the monitoring component in access control unit 18 ends the process's sleep state via the eBPF interface and executes it as described above.

[0070] In an extended variant, it is also possible for access policy 20, 30 to also include individual process names. With this variant, it is possible to extend the access authorization or the described procedure to non-containerized processes, so that these can also be prioritized differently.

[0071] This method can be used to prioritize and serialize more than just write access to files. For device files, the method has the advantage that the device's allocation and serialization takes place outside the device driver in a resource allocation component. Device-specific software can be scaled up and down in containers without the need for a device-specific resource management component. Non-container-specific processes can also be prioritized in the extended version. If, for example, Layer 2 protocol information is written to a system bus via the device files, individual, system-critical containers can issue control commands with priority on the runtime system based on their label, their container network technology, or the image name.

[0072] All method steps can be implemented by the corresponding device suitable for carrying out the respective method step. All functions that can be performed by physical features can be a method step of the method. All described and / or illustrated features can be advantageously combined with one another within the scope of the invention. The invention is not limited to the described embodiments.

Claims

1. Method for prioritizing access by a container instance (13) to a file (17) in a file system resource, comprising - receiving (S1), in a runtime environment (12) of the container instance, an access request (R1) for the container instance (13) to access the file (17), wherein the access request (R1) contains an access identifier (L1) which indicates at least one property of the accessing container instance (13), - checking (S2), by way of an access control unit (19) in the container runtime environment (12), the at least one property in the access identifier (L1) against an access guideline (20, 30) that comprises a prioritization level for accessing at least the one file (17) on the basis of the properties of the access identifier (L1), and - assigning (S3) an access authorization with a prioritization level to the access request (R1) on the basis of the checking result, - forwarding (S4) the access request (R1) to the file (17) on the basis of the assigned prioritization level.

2. Method according to Claim 1, wherein the file (17) is a device file which receives control instructions from the container instance (13) and forwards them for execution to a hardware resource (11) that can be controlled by the container instance (13).

3. Method according to Claim 2, wherein the access identifier (L1) is created specifically for the container instance (13), or the access identifier (L1) is created specifically for the container image and the container-image-specific access identifier is assigned to each container instance generated from the container image.

4. Method according to Claim 2 or 3, wherein the prioritization levels for accessing the hardware resource (11) by the container instance (13) are predefined by an operator of the hardware resource (11).

5. Method according to any one of the preceding claims, wherein the property in the access identifier (L1) is at least one from a selection of: a name of the access identifier, a signature of the accessing container instance, a signature of the container image, from which the container instance (13) is generated, a name of the container image.

6. Method according to any one of the preceding claims, wherein, if at least one network interface is assigned to the container instance (13), the access identifier (L1) contains an identifier for each of the at least one assigned network interfaces.

7. Method according to Claim 6, wherein the identifier of the assigned network interface is assigned to the network interface by an operator of the container runtime environment (12).

8. Method according to Claim 6 or 7, wherein the access guideline (20, 30) comprises a prioritization level for each of the identifiers of the network interfaces.

9. Method according to any one of the preceding claims, wherein that prioritization level which is assigned to the first property contained in the access identifier (L1) is assigned to the access request.

10. Method according to any one of Claims 1-8, wherein the highest prioritization level of all prioritization levels assigned to the properties contained in the access identifier (L1) is assigned to the access request (R1).

11. Method according to any one of the preceding claims, wherein the access guideline (20, 30) comprises, for each of the at least one file (17), a name of the file (17) and at least one property from a selection of the following properties: a name of the access identifier, a signature of the container instance (13), a signature of the container image, from which the accessing container instance (13) is generated, a name of the container image or an identifier for a network interface, and a prioritization level is assigned to at least one of the properties from the selection.

12. Method according to any one of the preceding claims, wherein the access guideline (20, 30) comprises, for each of the at least one file (17), at least one detail from a selection of: a process name for a process requested via the access request, an access mode, a maximum access duration, preferably on the basis of the properties of the access identifier.

13. Method according to any one of the preceding claims, wherein the access control unit (19) is in the form of an expansion module of the container runtime environment or in the form of an independent unit that is separate from the container runtime (12).

14. System (10) for prioritizing access by a container instance (13) to a file (17) in a file system resource, comprising a runtime environment (12) of a container instance (13), which is designed - to receive an access request (R1) for the container instance (13) to access the file (17), wherein the access request (R1) contains an access identifier (L1) which indicates at least one property of the accessing container instance (13), - to check, by way of an access control unit (19) in the container runtime environment (12), the at least one property in the access identifier (L1) against an access guideline (20, 30) that comprises a prioritization level for accessing at least the one file (17) on the basis of the properties of the access identifier (L1), and - to assign an access authorization with the prioritization level to the access request (R1) on the basis of the checking result, and - to forward the access request (R1) to the file (17) on the basis of the assigned prioritization level.

15. Computer program product comprising a non-volatile computer-readable medium which can be loaded directly into a memory of a digital computer, comprising program code parts which, when the program code parts are executed by the digital computer, cause the latter to carry out the steps of the method according to any one of Claims 1 to 13.