Prioritizing access to files in a file system resource by container instances

Abstract

A method for prioritizing access to a file (17) in a file system resource by a container instance (13) includes: receiving (S1) an access query (R1) for the container instance (13) to access the file (17) in a runtime environment (12) of the container instance, wherein the access query (R1) includes an access identifier (L1) that characterizes at least one characteristic of accessing the container instance (13); verifying (S2) at least one characteristic of the access identifier (L1) relative to access criteria (20, 30) by an access control unit (19) in the container runtime environment (12), the access criteria including a priority for accessing at least one file (17) based on the characteristic of the access identifier (L1); assigning (S3) a priority access authorization to the access query (R1) based on the verification result; and forwarding (S4) the access query (R1) to the file (17) according to the assigned priority.

Description

Technical Field

[0001] This invention relates to a method for prioritizing access to files in file system resources by a container instance. Background Technology

[0002] Container virtualization is a method in which multiple instances of an operating system can use the operating system kernel of a guest computer in isolation from each other. A software container (hereinafter simply referred to as a container) thus represents lightweight virtualization of the runtime environment on the guest computer (also known as the host system) and encapsulates the SW application running from the underlying host system within the container. SW applications, or services provided through SW applications, are implemented using containers in many fields, such as industrial automation and process control, and for applications in transportation systems or vehicles.

[0003] To start a container on a host system, a container image (also referred to below as a container image) is required. This container image contains, in addition to the application software, the binaries and libraries required by the application software. The container, more precisely, a container instance, is created from the container image on the host system and executed in a runtime environment. When needed, such as when the application is invoked by a user-enhanced application, other container instances can be created and executed on the same or different host systems from the same container image.

[0004] Traditionally, container instances are run using a container runtime environment such as Docker within the operating system of a host system, which is also configured as virtualized hardware resources when necessary. Files or file system regions on storage resources that the container instance or a process executing within the container instance wants to access, provided by the host system, are assigned to the container instance at startup, and access permissions for these files are assigned.

[0005] The host system's operating system uses access authorization assigned to a file to control which processes have access to that file. Here, multiple container instances of the same container image can run in parallel on the host system and can also access the file assigned to each container instance in parallel. Container instances of different container images can also use the same file. In both cases, and in many other situations, it is necessary to serialize write access to the file. Once a write operation occurs, it must be ensured that the write process performs its access exclusively within the expected time period.

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

[0007] SIEMENS AG CHRISTIAN KNIERIM DE- ET 1-15AL: "Definitionund von fürvertrauL1che Informationen inContainer-Instanzen″, PRIOR ART PUBLISHING GMBH, PRIOR ART PUBLISHING GMBH, MANFRED-VON-RICHTHOFEN-STR.9, 12101BERLIN GERMANY, Bd.www.priorartregister.com, July 15, 2021 (2021-07-15), pp. 1-5, XP007024163 describes a method for verifying complexity requirements or complexity rules for confidential information, the method automatically identifying the criticality of runtime parameters and performing complexity checks based on that identification.

[0008] US 2020 / 326984 A1 discloses a method for isolating file system resources for Docker containers. This method uses shared isolation-related "lock" contention and file system resource contention within the operating system kernel, whereby guest file system resources are allocated based on container access requests and lock resources are verified against the access requests.

[0009] Therefore, there is a need for a solution that ensures that write resources to device files are serialized for each instance or container image and are limited, delayed, or prioritized based on their trust level or characteristics. Furthermore, it should be ensured that such instances are terminated should the container instance block or persistently access the device file for an allowed duration in the worst-case scenario. Summary of the Invention

[0010] Therefore, the objective of this invention is to create a method that ensures file write resource usage is serialized for each container instance or container image and is limited, delayed, or prioritized according to its characteristics. This objective is achieved by the measures described in the independent claims. Advantageous improvements of the invention are shown in the dependent claims.

[0011] According to a first aspect, the present invention relates to a method for prioritizing access to files in a file system resource by a container instance, comprising:

[0012] - Receive an access query for the container instance to access a file in the container instance's runtime environment, wherein the access query contains an access identifier that characterizes at least one feature of the container instance.

[0013] - The access control unit in the container runtime environment examines at least one characteristic of the access identifier relative to access criteria, said access criteria including a priority for accessing at least one file based on the characteristics of the access identifier, and

[0014] - Assign priority access authorization to the access query based on the test results.

[0015] - Forward access queries to the file based on the assigned priority.

[0016] This enables the establishment and enforcement of specific access authorizations for files by container instances. Access identifiers can be constructed as labels, i.e., as jump flags. The characteristics in the access identifiers can be stored in the storage area marked by the jump flags and provided for verification. Access criteria can be used to link priorities to the characteristics of the container instance, specifying the processing order for accessing files. This allows for flexible assignment and enforcement of access authorizations.

[0017] In one advantageous implementation, the file is a device file that receives control instructions from the container instance and transfers the control instructions to hardware resources that can be controlled by the container instance for execution.

[0018] For example, when a container instance starts, hardware resources are assigned to the container instance via a configuration file. These hardware resources are also referred to as devices. Once a process within the container instance wants to send control commands to a device, the container instance delivers the control commands to a device file already created on the file system. The device file then delivers the control commands to a controller, which translates them into device-specific control commands. Therefore, container instance-specific priority access to devices can be granted through the container instance's access identifier in the access query.

[0019] In one advantageous implementation, an access identifier is created specific to the container instance. Alternatively, an access identifier is created specific to the container image, and the container image-specific access identifier is assigned to each container instance generated from the container image.

[0020] This allows for prioritization of access authorizations specific to each individual container instance. If access identifiers are created specific to the container image, the same access authorizations can be defined and enforced for all container instances created from that container image in a simple way.

[0021] In one advantageous implementation, the priority of access to hardware resources by a container instance is pre-defined by the operator of the hardware resources.

[0022] Thus, the operator of HW resources or the allocated devices can influence access to container instances with permitted access rights, even if the devices are not necessarily part of the overall host system.

[0023] In one advantageous implementation, the characteristics in the access identifier are selected from at least one of the following: the name of the access identifier, the signature of the access container instance, the signature of the container image from which the access container instance is generated, and / or the name of the container image.

[0024] Trust levels can be derived from the signature of a container instance or container image. Each selected characteristic can be assigned a priority for granting access to files or device files based on access criteria. Thus, access authorization can be flexibly linked to different characteristics.

[0025] In one advantageous implementation, 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 interface.

[0026] Therefore, access authorization can be prioritized based on the attributes of the network interface of the container instance.

[0027] In one advantageous implementation, the identifier of the assigned network interface is assigned to the network interface by the operator of the container runtime environment.

[0028] This allows the container runtime operator to control the container instance's access to network interfaces.

[0029] In one advantageous implementation, the access criteria include a priority for each identifier among the identifiers of the network interface.

[0030] This allows for fine-grained prioritization of access authorization based on each individual network interface.

[0031] In an advantageous implementation, the priority assigned to the first characteristic contained in the access identifier in the access criteria is assigned to the access query.

[0032] If, for example, multiple network interfaces are assigned to a single container instance, the priority for accessing the device file is pre-defined by the network interface mentioned first in the access identifier. Thus, the priority for accessing the device file can be pre-defined by the targeted order of the characteristics in the access identifier.

[0033] In an advantageous implementation, the highest priority among all priorities assigned to the characteristics contained in the access identifier is assigned to the access query.

[0034] This enables alternative interpretations of access identifiers.

[0035] In an advantageous implementation, the access criteria for each of the at least one file includes the file name and at least one characteristic selected from the following: the name of the access identifier, the signature of the access container instance, the signature of the container image from which the access container instance is generated, the name of the container image or the identifier for the network interface, and assigns a priority to at least one characteristic selected from the characteristics.

[0036] In the access criteria, attributes are assigned priorities. If an identifier of a container instance's network interface is assigned a higher priority, then the access query is preferentially processed compared to an access query from a container instance whose network interface is assigned a lower priority.

[0037] In an advantageous implementation, the access criteria for each of the at least one file preferably include at least one description of the following, based on the characteristics of the access identifier: the process name of the process being queried via the access query, the access mode, and the maximum access duration.

[0038] Therefore, the access guidelines can specify the access mode for each file, i.e., whether it can be accessed in a parallel write manner or in an exclusive manner, i.e., a serial write manner, to the HW hardware. As long as parallel write access is possible, the maximum number of write operations that can occur in parallel can be defined. The access mode, for example, specifies whether parallel access is allowed only through container instances of the same container image or through container instances of different container images.

[0039] In one advantageous implementation, the access control unit is configured as an extension module within the container runtime environment or as a separate unit independent of the container runtime.

[0040] By constructing the access control unit as an extended module, access authorization prioritization can be quickly performed on the host system. By constructing the access control unit as a standalone unit, processes can be better encapsulated by the container runtime environment and can also be bound to other concurrently running runtime environments. Alternatively, the access control unit can be distributed, for example, via an orchestrator to all systems managed by the orchestrator through a central deployment system.

[0041] A second aspect of the invention relates to an apparatus for prioritizing access to files in a file system resource by a container instance, the apparatus comprising a runtime environment for the container instance configured for

[0042] - Receive an access query for accessing a file within a container instance, wherein the access query contains an access identifier that characterizes at least one property of the container instance.

[0043] - The access control unit in the container runtime environment examines at least one characteristic of the access identifier relative to access criteria, said access criteria including a priority for accessing at least one file based on the characteristics of the access identifier, and

[0044] - Assign priority access authorization to the access query based on the test results.

[0045] - Forward access queries to the file based on the assigned priority.

[0046] With the device according to the invention, multiple container instances can access the same file simultaneously and be prioritized.

[0047] A third aspect of the invention relates to a computer program product comprising a non-volatile computer-readable medium that can be directly loaded into the memory of a digital computer, including a program code portion that, when executed by the digital computer, causes the digital computer to perform steps of a method.

[0048] Unless otherwise stated in the following description, the terms “receive,” “verify,” “assign,” “forward,” etc., preferably refer to actions and / or processes and / or steps of altering and / or generating data and / or transforming data into other data, wherein the data may, in particular, be represented as a physical parameter, or may exist as a physical parameter, such as an electrical pulse. The device and the runtime environment contained therein may include one or more processors.

[0049] Computer program products, such as computer program components, may be provided or supplied, for example, as storage media, such as memory cards, USB sticks, CD-ROMs, DVDs, or as files downloadable from a server on a network. This can be done, for example, by transferring the corresponding files to the computer program product or computer program component over a wireless communication network. Attached Figure Description

[0050] Embodiments of the method and device according to the invention are illustrated by way of example in the accompanying drawings and will be described in more detail below. Wherein:

[0051] Figure 1 An embodiment of the system according to the present invention is illustrated in schematic diagram, the system being configured as a host system having a runtime environment;

[0052] Figure 2 An embodiment of the method according to the present invention is illustrated as a flowchart;

[0053] Figure 3 An embodiment of the access identifier according to the present invention is illustrated schematically; and

[0054] Figure 4 An embodiment of the access criteria according to the present invention is illustrated in schematic diagram. Detailed Implementation

[0055] In all the accompanying drawings, corresponding parts are equipped with the same reference numerals.

[0056] according to Figure 1 The diagram illustrates the interaction between the various components of the system according to the invention, the container instance, and access to files assigned to the container instance.

[0057] Figure 1 The diagram illustrates system 10, HW resource 11, an operating system with container runtime environment 12, and two container instances 13 and 14 running on container runtime environment 12. HW resource 11 is, for example, a control device 15, a storage unit 16, or a network interface 18 physically constructed within the system. The network interface can also be constructed as a virtual network interface. Both the physical and virtual network interfaces are addressed via operating system kernel 22. File 17 is stored in a file system within storage unit 16. File 17 is assigned to container instance 13 and is therefore accessible by means of, for example, a "Bind-Mount" instruction or by partitioning another mount namespace containing file 17.

[0058] If container instance 13 or a process running on the instance wants to access file 17, the operating system or container runtime environment 12 controls which process gets access to the file based on access authorization.

[0059] If multiple container instances of the same container image are running in parallel on a host system, these container instances typically also access files allocated to each of the container instances in parallel. This is especially true when orchestration solutions such as Kubernetes identify and amplify overload situations for already running container instances—that is, when additional container instances are spawned from the same container image and launched. If too many container instances are launched, it is possible that, due to amplification, too many accesses to files are submitted and no longer processed correctly.

[0060] Furthermore, container instances of different container images can use the same file and execute different tasks on the same controller. These container images may also be provided by different manufacturers and do not always have the same confidentiality level. If file 17 receives control instructions from container instance 13 and transfers those control instructions to a hardware resource 11 that can be controlled by container instance 13, such as a device file used by control device 15 for execution, then in a conventional system, a malicious container instance could use control device 15 connected to the device file by permanently writing to the device file, making it impossible for control signals related to the operational security of other container instances to be interrupted, and thus the security of the host system or the facility running container instances through a cloud-based host system is compromised.

[0061] In both cases, it is usually necessary to serialize write accesses to the file, meaning that the write process is performed sequentially in time rather than simultaneously.

[0062] The basic idea is that container instances 13 and 14 have certain characteristics, and access to file 17 is prioritized based on one or more of these characteristics.

[0063] exist Figure 2 The present invention illustrates a method for prioritizing access to file system resources, such as files, such as file 17, in storage unit 16 by a container instance, such as container instance 13.

[0064] In the first method step S1, the runtime environment 12 of container instance 13 receives an access query R1 for container instance 13 to access file 17. This access query includes an access identifier L1, which describes at least one characteristic of the container instance 13 for access. File 17 can be any type of file, but in particular, it can also be a device file. The access identifier L1 is created specific to container instance 13 such that a unique access identifier L1 is assigned to each container instance 13. The access identifier L1 can also be created specific to the container image such that the same container image-specific access identifier is assigned to each container instance created from the same container image.

[0065] In the next method step S2, at least one characteristic of the access identifier L1 is checked relative to access criterion 20 and AR, and the access control unit 19 in the container runtime environment 12 determines the access priority to file 17 based on access criterion 20 and AR based on the characteristics of access identifier L1. Then, an access authorization with the priority AP obtained from the check is assigned to access query R1, see method step S3. For example, access query R1 is queued in queue 21 according to priority AP for delivery to file 17. Then, access query R1 is forwarded to file 17 according to the assigned priority AP.

[0066] If file 17 is a device file, it can be pre-defined by the hardware resource operator, and thus the manufacturer of device 15, for accessing hardware resources addressable by the device file, such as the priority AP controlling device 15.

[0067] The access control unit 19 is configured as an extension module of the container runtime environment 12 in system 10 or as a separate unit independent of the container runtime. System 10, having runtime environment 12, is configured to execute the described methods.

[0068] exist Figure 3 An embodiment of the access identifier L1 is illustrated. The access identifier L1 of container instance 13 includes at least one of the characteristics of container instance 13. Here, the characteristic may in particular be the name LN1 of the access identifier L1, the signature S1 of container instance 13, the signature SI1 of the container image, or the name O1 of the container image from which access to container instance 13 is generated. If one or more network interfaces are assigned to container instance 13, the access identifier may include an identifier NW1 for each of the assigned network interfaces. The identifier NW1 is preferably assigned to the network interface by the operator of container runtime environment 12.

[0069] Figure 4An embodiment of access criteria 30, AR is illustrated. Access criteria 30, AR, for each file in at least one of the files 17, includes the names DN1, DN2 of the corresponding file and at least one characteristic of the container instance authorized for access. Furthermore, the access criteria include at least one priority Prio1, Prio2. Characteristics are assigned to at least one priority Prio1, Prio2 based on the characteristics included in the access identifier. Therefore, the characteristics included in the access identifier L1 are examined relative to the characteristics in access criteria 30, AR. The corresponding priority Prio1, Prio2 assigned to the first characteristic included in the access identifier is assigned to the access query. In this practice, also known as the First-Hit method, priorities Prio1, Prio2 are used for the file to which write access should be controlled, the priorities applying to the first characteristic in the access identifier of the container instance. Alternatively, the highest priority can also be assigned to the access query with respect to all characteristics mentioned in the access identifier.

[0070] Figure 4 The possible characteristics to be selected in the access criteria are shown: the name LN1 of the access identifier L1, the signature S1 of the access container instance 13, the signature SI1 of the container image from which the access container instance is generated, the name O1 of the container image, or the identifier NW1 of the network interface. Each characteristic is assigned a priority. For each of at least one file 17, the access criteria 20, AR preferably includes at least one piece of information based on the characteristics of the access identifier or based on the corresponding process: the process name of the container instance being queried via the access query, process names P3 and P4, access mode, and maximum access duration. For each file 17, it can be specified whether the file can be accessed in a parallel write manner or in an exclusive write manner. As long as access in a parallel write manner is allowed, the maximum number of write actions that can occur in parallel can be defined.

[0071] The network interface identifier NW1 allows for the following possibility: prioritizing access to file 17 via the container instance's attribute to the network interface (also known as the network bridge). It is possible to segment container instances on the network side using the network interface. Therefore, access criteria 20, 30, and AR can ensure that container instances running in more critical data networks can be given higher priority.

[0072] If a container instance connects to multiple network interfaces, then access rules 20, 30, and AR must also define whether to use the rule for the network interface with the lowest priority or the rule for the network interface with the highest priority. To this end, the network interface must be prioritized accordingly, either by the operator of the HW resource addressed through the network interface or by the configurator of the application running in the container instance. This can be achieved by defining the priority of access identifiers or the order of characteristics within the access rules and / or the characteristics in the access identifiers.

[0073] The same applies to container instances or container images whose access identifiers contain multiple attributes of the same type, such as multiple signatures.

[0074] Access rule 20, AR is controlled by access control unit 19 (see...) Figure 1 The access control unit 19 is implemented either 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 access criteria 20 and 30 in the event of an access query R1 from a process of container instance 13 to file 17. This monitoring program generates alerts, for example, via an extended Berkeley Packet Filter (eBPF) interface of operating system kernel 22 and transmits these alerts to the monitoring component within the access control unit 19. The process is initially temporarily interrupted and stopped by the eBPF program; in other words, it is put to sleep.

[0075] Access control unit 19 first checks whether the process belongs to a container instance that has been granted access. To determine whether a process belongs to container instance 13, access control unit 19 may interact with container runtime environment 12 via a communication interface, such as Docker-Socket. Alternatively, access control unit 19 may register process namespaces started in container runtime environment 12 and monitor other processes started in those namespaces, for example, using eBPF programs.

[0076] Upon receiving an access request for file 17 or upon starting container instance 13, access control unit 19 determines additional information, such as tags belonging to a network interface, container image, or container instance. Access control unit 19 queries this information from the container runtime environment 12, for example, via Docker-Socket or the corresponding programming interface. Access control unit 19 further determines which interfaces the network interface 18 assigned to container instance 13 connects to. This is determined in advance when adding or removing network interfaces. Whenever relevant characteristics such as the container image name or signature are determined before accessing file 17, such as at startup and when changing or stopping container instance 13, parameters stored in access criteria 20 for each container instance are intermediately stored in access control unit 19.

[0077] The signature information of the container image belonging to container instance 13 is determined directly through the access control unit 19. This can be done by the access control unit directly accessing the cached image and signature data of the container runtime environment 12 and executing the cached image and signature data itself, or by reading the corresponding information from the container runtime environment 12 through the corresponding interface command, and trusting that the access control unit can perform the correct verification.

[0078] If file 17 can be used exclusively or the maximum number of concurrent write processes has not been reached, the access control unit 19 notifies the operating system, and in particular the operating system kernel 22, via the eBPF interface that the process put to sleep by the access control unit can be executed. Once the process finishes writing to file 17, the operating system kernel 22 also notifies the access control unit 19 via a defined eBPF procedure.

[0079] The maximum access duration for container instance 13 can be defined globally for file 17 or for each characteristic in the access identifier. Access control unit 19 monitors the maximum access duration stored in access criteria 20. If the corresponding maximum access duration is exceeded, access can remain permitted as long as no other access queries for that file exist. If an access query involves a device file, longer access can be permitted if no other resource requests are made for the HW resource addressed by the device file. If an access query is made for file 17, access control unit 19 can instruct the container instance 13 to immediately release access and / or terminate the process using the device file beyond the allowed duration. This can be done, for example, using the corresponding inter-process communication mechanism in the operating system.

[0080] Instead of terminating the process, it can simply be put back to sleep, provided that parallel write access to the device file is possible. This is possible because it is assumed that when using file 17 in parallel, access serialization does not need to be performed; instead, only container instances with higher priority access to file 17, such as container instance 14, must be prioritized. If file 17 is occupied and a new process wants to access it, the access control unit 19 checks its priority and assigns the new process to the process queue 21 that is generated for its priority. The process queue 21 is processed according to its priority via process scheduling in core 22. Once access to file 17 is possible, the monitoring component in the access control unit 18 terminates the process's sleep state via the eBPF interface and executes the process as described above.

[0081] In an extended variant, it is also possible that access rules 20 and 30 additionally include the names of the individual processes. In this variant, it is also possible to extend access authorization or the described methods to non-containerized processes, allowing these processes to be prioritized in a different manner.

[0082] This method not only prioritizes and serializes write access to files, but also offers the advantage of prioritizing device files, as device assignment and serialization occur outside the device driver within the resource delegation component. Device-specific software can be scaled up and down within containers without requiring device-specific resource control components. In this extended variant, non-container-specific processes can also be prioritized. By writing Layer 2 protocol information to the system bus via device files, for example, each system-critical container can issue control commands in a prioritized manner on the runtime system based on its tag, container networking technology, or image name.

[0083] All method steps can be implemented by corresponding apparatus suitable for performing the respective method steps. All functions that can be performed by specific features can be method steps of the method. All features described and / or drawn can be advantageously combined with each other within the scope of the invention. The invention is not limited to the described embodiments.

Claims

1. A method for prioritizing and serializing write accesses of a container instance (13) to a file system resource (17), wherein the file (17) is a device file that receives control instructions from the container instance (13) and transfers the control instructions to a hardware resource (11) controllable by the container instance (13) for execution, the method comprising: - In the container runtime environment (12) of the container instance, an access query (R1) is received (S1) for the container instance (13) to access the file (17), wherein the access query (R1) contains an access identifier (L1) that characterizes at least one characteristic of the container instance (13) for access. - The access control unit (19) in the container runtime environment (12) verifies (S2) at least one characteristic of the access identifier (L1) relative to access criteria (20, 30), the access criteria including a priority for accessing at least one file (17) based on the characteristics of the access identifier (L1), and -Based on the test results, assign (S3) priority access authorization to the access query (R1). - The access query (R1) is forwarded (S4) to the file (17) according to the assigned priority so as to serialize the write access.

2. The method of claim 1, wherein the access identifier (L1) is created specifically for the container instance (13) or specifically for the container image, and the container image-specific access identifier is assigned to each container instance generated from the container image.

3. The method according to claim 1 or 2, wherein the priority for access to the hardware resource (11) by the container instance (13) is pre-given by the operator of the hardware resource (11).

4. The method according to any one of claims 1 to 2, wherein the characteristics in the access identifier (L1) are at least one of the following: the name of the access identifier, the signature of the access container instance, the signature of the container image from which the container instance (13) is generated, and the name of the container image.

5. The method according to any one of claims 1 to 2, 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 interface.

6. The method of claim 5, wherein the identifier of the assigned network interface is assigned to the network interface by the operator of the container runtime environment (12).

7. The method of claim 5, wherein the access criteria (20, 30) include a priority for each of the identifiers of the network interface.

8. The method according to any one of claims 1 to 2, wherein the priority assigned to the first characteristic contained in the access identifier (L1) is assigned to the access query.

9. The method according to any one of claims 1 to 2, wherein the highest priority among all priorities assigned to the characteristics contained in the access identifier (L1) is assigned to the access query (R1).

10. The method according to any one of claims 1 to 2, wherein the access criteria (20, 30) for each of the at least one file (17) has the name of the file (17) and at least one characteristic selected from the following characteristics: the name of the access identifier, the signature of the container instance (13), the signature of the container image from which the access container instance (13) is generated, the name of the container image or the identifier for the network interface, and a priority is assigned to at least one characteristic selected from the following characteristics.

11. The method according to any one of claims 1 to 2, wherein the access criteria (20, 30) for each of the at least one file (17) includes at least one description of the following: process name, access mode, and maximum access duration for the process queried via the access query.

12. The method of claim 11, wherein the access criteria (20, 30) for each of the at least one file (17) include at least one description of the following based on the characteristics of the access identifier: the process name of the process being queried via the access query, the access mode, and the maximum access duration.

13. The method according to any one of claims 1 to 2, wherein the access control unit (19) is configured as an extension module of the container runtime environment or as an independent unit separate from the container runtime environment (12).

14. A system (10) for prioritizing and serializing write accesses of a container instance (13) to a file system resource (17), the system comprising a runtime environment (12) of the container instance (13), wherein the file (17) is a device file that receives control instructions from the container instance (13) and transfers the control instructions to hardware resources (11) that can be controlled by the container instance (13) for execution, the system being configured for - Receive an access query (R1) for the container instance (13) to access the file (17), wherein the access query (R1) contains an access identifier (L1) that characterizes at least one property of the container instance (13). -At least one characteristic of the access identifier (L1) is examined relative to access criteria (20, 30) by the access control unit (19) in the container runtime environment (12), the access criteria including a priority for accessing at least one file (17) based on the characteristics of the access identifier (L1), and - Assign priority access authorization to the access query (R1) based on the test results. - The access query (R1) is forwarded to the file (17) according to the assigned priority so as to serialize the write access.

15. A computer program product comprising a non-volatile computer-readable medium that can be directly loaded into the memory of a digital computer, including a program code portion that, when executed by the digital computer, causes the digital computer to perform the steps of the method according to any one of claims 1 to 13.

Images