IBM Novell 10 SP1 EAL4 Скачать руководство пользователя страница 61

Страница: 61 / 246

5.1.5.2.3 ACL permissions

An ACL entry can define separate permissions for read, write, and execute or search.

5.1.5.2.4 Relationship to file permission bits

An ACL contains exactly one entry for each of the

ACL_USER_OBJ

ACL_GROUP_OBJ

, and

ACL_OTHER

types of tags, called the required ACL entries. An ACL can have between zero and a defined maximum
number of entries of the

ACL_GROUP

and

ACL_USER

types. An ACL that has only the three required ACL

entries is called a minimum ACL. ACLs with one or more ACL entries of the

ACL_GROUP

ACL_USER

types are called extended ACLs.
The standard UNIX file permission bits as described in the previous section are equivalent to the entries in the
minimum ACL. The owner permission bits correspond to the entry of the

ACL_USER_OBJ

type. The entry

of the

ACL_GROUP_OBJ

type represents the permission bits of the file group. The entry of the

ACL_OTHER

type represents the permission bits of processes running with an effective user ID and effective group ID or
supplementary group ID different from those defined in

ACL_USER_OBJ

and

ACL_GROUP_OBJ

entries.

Minimum ACLs do not need to be stored on disk. The permission information contained in the

inode

sufficient for the access check. When adding ACL entries to a file system object that did not previously have
an explicit ACL, the kernel creates a minimum ACL based on the

inode

attributes, and then adds the new

entries to that.

5.1.5.2.5 ACL_MASK

If an ACL contains an

ACL_GROUP

ACL_USER

type of entry, then exactly one entry of the

ACL_MASK

type is required in the ACL. Otherwise, the

ACL_MASK

type of entry is optional.

5.1.5.2.6 Default ACLs and ACL inheritance

A default ACL is an additional ACL, which can be associated with a directory.  This default ACL has no
effect on the access to this directory.  Instead, the default ACL is used to initialize the ACL for any file that is
created in this directory.  When an object is created within a directory, and the ACL is not defined with the
function creating the object, the new object inherits the default ACL of its parent directory as its initial ACL.
This is implemented by

ext3_create()

, which invokes

ext3_new_inode()

, which in turn invokes

ext3_init_acl()

to set the initial ACL.

5.1.5.2.7 ACL representations and interfaces

ACLs are represented in the kernel as extended attributes. The kernel provides system calls such as

getxattr()

setxattr()

listxattr()

, and

removexattr()

to create and manipulate extended

attributes.  User space applications can use these system calls to create and maintain ACLs and other extended
attributes.  However, ACL applications, instead of directly calling system calls, use library functions provided
by the POSIX 1003.1e compliant libacl.so.  Inside the kernel, the system calls are implemented using the

getxattr

setxattr

listxattr

, and

removexattr

inode operations. The kernel provides two

additional inode operations,

get_posix_acl()

and

set_posix_acl()

, to allow other parts of the

kernel to manipulate ACLs in an internal format that is more efficient to handle than the format used by the
inode xattr operations.
In the ext3 disk-based file system, extended attributes are stored in a block of data accessible through the

i_file_acl

field of the

inode

. This extended attribute block stores name-value pairs for all extended

attributes associated with the

inode

. These attributes are retrieved and used by appropriate access control

functions.