IBM 10 SP1 EAL4 Manuale Utente
•
Unbindable Mount: This mount does not forward or receive propagation. This mount type can not be
bind-mounted, and it is not valid to move it under a shared mount.
bind-mounted, and it is not valid to move it under a shared mount.
•
Slave Mount: A slave mount remains tied to its parent mount and receives new mount or unmount
events from there. The mount or unmount events in a slave mount do not propagate elsewhere.
events from there. The mount or unmount events in a slave mount do not propagate elsewhere.
•
Shared Mount: When this mount is used, all events generated are automatically propagated to the
shared mount subtree. Shared mounts are able to propagate events to others belonging to the same
peer group.
shared mount subtree. Shared mounts are able to propagate events to others belonging to the same
peer group.
•
Private Mount: This works as the previous existent mount. Private mounts cannot be propagated to
any other mounts, except when forced by administrators using the bind operation. Any kind of
mounts can be converted to private mounts.
any other mounts, except when forced by administrators using the bind operation. Any kind of
mounts can be converted to private mounts.
5.1.2 Disk-based file systems
Disk-based file systems deal with how the data is stored on the disk. Different disk-based file systems
employ different layouts and support different operations on them. For example, the CD-ROM file system
does not support the write operation. The TOE supports two disk-based file systems: ext3, and the ISO 9660
File System for CD-ROM.
This section looks at data structures and algorithms used to implement these two disk-based file systems and
continues the description of open() and write() system calls in the context of disk-based file systems.
employ different layouts and support different operations on them. For example, the CD-ROM file system
does not support the write operation. The TOE supports two disk-based file systems: ext3, and the ISO 9660
File System for CD-ROM.
This section looks at data structures and algorithms used to implement these two disk-based file systems and
continues the description of open() and write() system calls in the context of disk-based file systems.
5.1.2.1 Ext3 file system
The SLES kernel’s ext3 file system kernel is a robust and efficient file system that supports the following:
•
Automatic consistency checks
•
Immutable files
•
Preallocation of disk blocks to regular files
•
Fast symbolic links
•
ACLs
•
Journaling
The file system partitions disk blocks into groups. Each group includes data blocks and inode blocks in
adjacent tracks, which allow files to be accessed with a lower average disk seek time. In addition to the
traditional UNIX file object attributes such as owner, group, permission bits, and access times, the SLES ext3
file system supports Access Control Lists (ACLs) and Extended Attributes (EAs). ACLs provide a flexible
method for granting or denying access, which is granular down to an individual user, directory, or file.
adjacent tracks, which allow files to be accessed with a lower average disk seek time. In addition to the
traditional UNIX file object attributes such as owner, group, permission bits, and access times, the SLES ext3
file system supports Access Control Lists (ACLs) and Extended Attributes (EAs). ACLs provide a flexible
method for granting or denying access, which is granular down to an individual user, directory, or file.
5.1.2.1.1 Extended Attributes
An extended attribute (EA, aka xattr) provides a mechanism for setting special flags on a directory or a file.
Some of these improve the usability of the system, while others improve the security of the system. EAs also
provide a mechanism that allows persistent storage of security attributes—DAC ACLs.
The EA namespace is partitioned. ACLs make use of reserved namespaces with access restricted to
administrative users (and object owner in some cases). Special checks are performed in the xattr syscalls to
ensure that only administrative users and privileged system services can access the reserved namespaces. The
system.posix_acl_access and system.posix_acl_default namespaces are reserved for ACL metadata. This
namespace is restricted to the object owner and is accessible by administrative users.
Some of these improve the usability of the system, while others improve the security of the system. EAs also
provide a mechanism that allows persistent storage of security attributes—DAC ACLs.
The EA namespace is partitioned. ACLs make use of reserved namespaces with access restricted to
administrative users (and object owner in some cases). Special checks are performed in the xattr syscalls to
ensure that only administrative users and privileged system services can access the reserved namespaces. The
system.posix_acl_access and system.posix_acl_default namespaces are reserved for ACL metadata. This
namespace is restricted to the object owner and is accessible by administrative users.
39