Extended Attributes


Most of the time, the traditional Linux/Unix file permission system fits the security needs of an organization just fine. However, in today's highly collaborative environment where multiple users need access to files, this scheme can become inadequate or cumbersome to use. The newer Linux kernels introduced access control lists (ACLs) as an extension of the traditional file permission concept. While ACLs do not inherently add "more security" to a system, they do help to reduce the complexity of managing permissions. Supported by the ext2, ext3, ReiserFS, JFS, and XFS filesystems, ACLs provide new ways to apply file and directory permissions without resorting to the creation of unnecessary groups.

You cannot use chmod to manipulate these secondary ACLs because they are stored separately from the standard Linux permissions. Instead, you need to use setfacl and getfacl, as discussed later in this section. Furthermore, to make use of ACLs, both the kernel and the filesystem used must support them.

ACL SUPPORT IN SAMBA

To make Samba as portable as possible, its designers decided against a custom implementation of ACLs. Instead, each Samba server converts Windows ACL specifications (sent via MS-RPC) into a POSIX ACL and then converts that neutral ACL into an ACL that's platform-specific.

If the Samba server's underlying filesystem supports ACLs, and the POSIX ACL can be converted to a native ACL, Windows users can manipulate server-side ACLs on the Samba server using common Windows utilities.

Samba 2.2 and later included support for ACLs, and it will preserve NTFS ACLs rather than mapping ACL permissions to the less-flexible, standard Unix permissions. Native ACL support, in combination with winbind, allows a Linux-based Samba system such as SLES 9 to "assimilate" Windows NT and higher users, groups, and ACL permissions.


ACLs are stored as extended attributes (EAs) within the filesystem metadata. As the name implies, they allow you to define lists that either grant or deny access to a given file based on the criteria you provide. ACLs do not replace but instead coexist with the traditional permission system; they can be specified for users and groups and are still separated into the realms of read, write, and execute rights. In addition, an ACL may be defined for any user or group that does not correspond to any of the user or group ACLs, much like the "other" mode bits of a file. The ACLs also have what is called an ACL mask, which acts as a permission mask for all ACLs that specifically mention a user or a group (so-called named user or named group ACLs). This mask is similar to the umask but not quite the same. For example, if you set the ACL mask to r--, any ACLs that pertain to a specific user or group and are "looser" in permission (for example, rw-) will be "masked out" and effectively become r--.

ACL masks work similarly to the Inherited Rights Mask (IRM) used by the NetWare file system, where each named ACL is logically ANDed with the ACL mask to obtain an effective ACL; a named ACL can be compared to a NetWare user or group trustee assignment. The main difference here is that in Linux, a named ACL takes precedence over a named group ACL, whereas in NetWare, both assignments are combined to get an overall privilege. For example, Carol belongs to the group users. If there is a named user ACL for username carol and a named group ACL for groupname users, the mode assigned to the named user ACL is compared with the ACL mask to determine the effective ACL; the name group ACL is ignored in this case.

SECURING FILES USING EXTENDED ATTRIBUTES

With ext2/ext3 filesystems, there is an EA called the "immutable" bit. A file with this bit set (using chattr +i filename) cannot be modified in any way: It can't be renamed or deleted, no links can be created to this file, and no data can be added to this file. Only a process with the CAP_LINUX_IMMUTABLE privilege or the root user can set or clear this attribute. If a file with the u (undeletable) attribute set is deleted, its contents are saved and thus can be undeleted. See man chattr for other EA attributes. (File undelete is not possible on an ext3 filesystem; see batleth.sapienti-sat.org/projects/FAQs/ ext3-faq.html for an explanation.)

Use lsattr to list the EAs on an ext2/ext3 filesystem.


Directories may also contain default ACLs, which specify the initial ACLs of files and subdirectories created within them.

To add, modify, or remove ACLs, you use the setfacl command. To add or modify an ACL, you use the -m flag, followed by one or more comma-separated ACL specifications and one or more filenames. To delete an ACL, you use the -x flag instead. The general command syntax is

 setfacl option_flag acl_specification filename 

There are four general forms of an ACL: one for users, another for groups, one for others, and one for the ACL mask, as shown in Table 6.10. Notice that for the user and group ACLs, the actual user and group names that the ACL applies to are optional. If they are omitted, the ACL will apply to the base ACL, which is derived from the file's mode bits. Thus, if you modify them, the mode bits will be modified and vice versa, as illustrated by the following example:

 Athena:/home/testuser # touch testfile Athena:/home/testuser # ls -l testfile -rw-r--r--  1 testuser users 0 2005-01-12 10:15 testfile Athena:/home/testuser # setfacl -m g::---,o:--- testfile Athena:/home/testuser # ls -l testfile -rw------- 1 testuser users 0 2005-01-12 10:15 testfile 

Table 6.10. ACL Specifications

TYPE

SYNTAX

User

u[ser]:[username]:mode

Group

g[roup]:[groupname]:mode

Other

o[ther]:mode

ACL mask

m[ask]:mode


Consider the following example in which user eric is given read and write access to a file called report:

 Athena:/home/testuser # ls -l report -rw-rw-r--  1 testuser users 0 2005-01-12 10:25 report Athena:/home/testuser # setfacl -m u:eric:rw- report Athena:/home/testuser # ls -l report -rw-rw-r--+ 1 testuser users 0 2005-01-12 10:25 report Athena:/home/testuser # getfacl report # file: report # owner: testuser # group: users user::rw- user:eric:rw- group::rw- mask::rw- other::r-- 

TIP

In the ls output after the setfacl command, notice the + after the permission bits. This symbol indicates the file has extended attributes associated with it.


The getfacl command displays ACLs and other file information. The first three lines show the file's name (report), the file's owner (testuser), and the group owner (users). The line user:rw- and the lines group::rw- and other:r-- simply reflect the traditional file mode permission bits. The user:eric:rw- line is the new, named user ACL (where a specifically named user is given an ACL assignment). Assume that Eric is not a member of the group users. This named ACL has just granted Eric read and write access to the file. Without the use of ACLs, either Eric would just have read access (as a result of the world permission bits), or you would have to add him to the group users to grant him read/write access.

Now, if you change the ACL mask to r--, the ACL for Eric would effectively become r-- as well:

 Athena:/home/testuser # setfacl -m m:r-- report Athena:/home/testuser # getfacl report # file: report # owner: testusre # group: users user::rw- user:eric:rw-          #effective:r-- group::rw- mask::rw- other::r-- 

As mentioned earlier, directories can have default ACLs that will automatically be applied to files and subdirectories that are created within it. You set default ACLs by prepending a d: to the ACL that you want to set:

 Athena:/home/testuser # mkdir testdir Athena:/home/testuser # setfacl -m d:u:eric:rw- testdir Athena:/home/testuser # getfacl testdir # file: testdir # owner: testuser # group: users user::rwx group::r-x other::r-x default:user::rwx default:user:eric:rw- default:group::r-x default:mask::rwx default:other::r-x Athena:/home/testuser # touch testdir/blah Athena:/home/testuser # getfacl testdir/blah # file: testdir/blah # owner: testusre # group: users user::rw- user:eric:rw- group::r-x          #effective:r-- mask::rw- other::r-- 

As you can see here, Eric's ACL has been applied to the newly created file under testdir. When the default ACL is set, the umask no longer influences the permissions of new files.

In short, ACLs let you maintain fine-grained control over your files. With ACLs, you can avoid the risk of granting privileges too widely.



    SUSE LINUX Enterprise Server 9 Administrator's Handbook
    SUSE LINUX Enterprise Server 9 Administrators Handbook
    ISBN: 067232735X
    EAN: 2147483647
    Year: 2003
    Pages: 134

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net