The logical abstractions provided by the Linux file system component were studied to determine the set of object classes that needed to be labeled and controlled by the Flask mechanisms. The set of object classes for the file system component is shown in Table 7. Three abstractions that need to be controlled, pipes, files, and directories, were immediately evident in the Linux API. Files were further refined into separate object classes for each file type defined by the Linux API, i.e. regular files, symbolic links, character devices, block devices, FIFOs, and Unix domain socket files.
When a pipe is created, it inherits the SID of the creating process by default. When a directory or file is created, it is assigned a SID that represents the security context in which it is created by default. This context depends on the security context of the creating process and the security context of the parent directory. Since the computation of the new security context may involve policy-specific logic, it must be computed by the security server.
Although file systems are not treated as first-class objects in the Linux API, a separate object class was defined for the file system abstraction. Entire file systems are labeled not only to control operations such as mounting and unmounting but also to represent the aggregate label of all files within the file system.
Finally, an object class was defined for the file description abstraction. The term file description is used by POSIX  to describe the information referenced by a file descriptor, e.g. the file offset, file status and file access modes for an open file. File descriptors may be inherited across execve calls, and they may be transferred through IPC. Consequently, it is necessary to label and control file descriptions. The SID of a file description is inherited from the SID of the process that created it.