Extended file attributes (EA) are extensions to the normal attributes which are associated with inodes in a file system.  They are simply name:value pairs associated with files and directories and whose purpose is to provide additional functionality which is either defined by the operating system or a user application.  An EA may be defined or undefined.  If an EA is defined, its value may be empty or non-empty.  Most of the initial work to support EAs in Linux was done by Andreas Gruenbacher in the 2001 to 2004 timeframe and is based on work done in the SGI XFS file system.

EAs are stored directly in inodes and on additional disk blocks if necessary.  Currently all EAs associated with a file must fit in an inode and one additional block.  Blocks that contain the identical set of EAs may be shared among several inodes.  EAs in inodes and on blocks have a different header followed by multiple entry descriptors.  Entry descriptors are sorted in disk blocks but are left unsorted in inodes.

EA names are zero-terminated strings and are always specified using a fully qualified namespace.attribute e.g. system.posix_acl_access or security.selinux.  Namespaces are used to define different classes of EAs.  Different EA classes are required because the permissions and capabilities required for manipulating EAs in one namespace may differ from one to another.  Currently Linux supports EA namespaces for SELinux (security.), system (system.), trusted (trusted.) and user (user.).

Fedora 11 comes with EA support in the Linux kernel and hence it is the kernel which must be modified in order to add another EA namespace.  In my case I wanted to add an EA namespace called snia in order to support XAM XSet metadata (see below).

Here is the patch file for the Fedora 11 2.6.29.4-167.fc11 kernel which implements the snia namespace.  It should work for both 32-bit and 64-bit kernels but I have only tested it on a 64-bit kernel. diff ]]> http://blog.fpmurphy.com/2009/06/fedora-11-extended-attibutes-namespace.html/feed 2 http://blog.fpmurphy.com/2009/06/fedora-11-nvidia-twinview-support.html http://blog.fpmurphy.com/2009/06/fedora-11-nvidia-twinview-support.html#comments Thu, 11 Jun 2009 17:07:00 +0000 fpmurphy http://blog.fpmurphy.com/2009/06/fedora-11-nvidia-twinview-support.html Fedora 11 (Leonidas) ships with the nouveau nVidia graphics driver preloaded by default if a nVidia graphics card is detected at install time.  Previous versions of Fedora used the older X.Org nv driver.

The nouveau project aims at producing Open Source 3D drivers for nVidia graphics cards.  According to the nouveau project Wiki

2D-support is in fairly good shape with EXA acceleration, Xv and Randr12 (think of dual-head, rotations, etc.). Randr12 should work for all cards up to, and including, Geforce 9000 series, although some issues with Geforce 8/9 laptops may still exist, for such issues bug reports should be submitted. Randr12 is now the default. Any 3D functionality that might exist is still unsupported, do not ask for instructions to try it. Also, VT switching while X is running is considered lucky.”

Well, I certainly quickly ran into the VT switching issue!  It worked but not consistently.

Unfortunately the nouveau driver currently does not support nVidia TwinView functionality and I suspect that it will be a long time before it does if ever!

To use TwinView with Fedora 11, you have to load the correct nVidia drivers from rpmfusion.org.  I described how to do this in detail in a previous post so I will not repeat that information here.

You also need to modify your grub.conf file to include the nopat kernel boot option as shown below. title Fedora (2.6.29.4-167.fc11.x86_64) root (hd0,1) kernel /vmlinuz-2.6.29.4-167.fc11.x86_64 ro root=/dev/mapper/vg_ultra-lv_root rhgb quiet nopat initrd /initrd-2.6.29.4-167.fc11.x86_64.img

The nopat option is needed for this particular kernel (2.6.29.4) as it appears to still have broken PAT functionality.

For those readers who are unaware of what PAT is, here is a brief explanation.  Traditionally page caching was controlled by a CPU feature called Memory Type Range Registers (MTRR).  A CPU has a finite and limited set of MTRRs each of which control part of the physical address space.  To overcome this limitation and provide a more flexible architecture, Intel and other x86 CPU vendors added a set of bits to page table entries to control how a CPU does page caching.  These bits are called the Page Attribute Table (PAT).  Incidentally, the 2.6.26 kernel was the first Linux kernel to support PATs.

Unless you rebuild your initial ramdisk (initrd), the nouveau driver will remain loaded in the kernel.  I prefer not to have the nouveau driver loaded in my kernel if I am ]]> http://blog.fpmurphy.com/2009/06/fedora-11-nvidia-twinview-support.html/feed 0 http://blog.fpmurphy.com/2009/05/linux-security-capabilities.html http://blog.fpmurphy.com/2009/05/linux-security-capabilities.html#comments Thu, 28 May 2009 15:14:00 +0000 fpmurphy http://blog.fpmurphy.com/2009/05/linux-security-capabilities.html In earlier times, the standard security model for GNU/Linux and Unix operating systems gave general users a minimal set of privileges, while granting full privileges to a single user account, i.e. root, that was used to administer the system and users, install software, mount and unmount filesystems, loading kernel modules, bind a process to a privileged port and run many services.

This dependence upon the root account to perform all actions requiring privilege was recognized to be somewhat dangerous in that it was all or nothing and not suited to compartmentalization of roles.  Furthermore, it increased the risk of vulnerabilities within a setuid application which may only require root privileges for a very small fraction of its activity such as opening a system file or binding to a privileged port.

This risk was well understood within the open systems community.  As a result, IEEE Std.1003.1e (aka POSIX.1e or POSIX.6) was a major effect started in 1995 to develop a standardized set of security interfaces for conforming systems which included access control lists (ACL), audit, separation of privilege (capabilities), mandatory access control (MAC) and information labels.

The work was terminated by IEEE’s RevCon in 1998 at draft 17 of the document due to lack of consensus (mostly because of conflicting existing practice.)  While the formal standards effort failed, since then much of the draft standard has made its way in the Linux kernel including capabilities which this post explores.

First, what do we mean by Linux capabilities?  It is basically an extended verion of the capabilities model described in the draft POSIX.1e standard.  Readers familiar with VMS or versions of Unix which include Trusted Computing Base (TCB) will recognize it as being somewhat analogous to as privileges.  These capabilities partition the set of root privlileges into a set of distinct logical privileges which may be granted or assigned to processes, users, filesystems and more.  As an aside, the term capability originated in a 1966 paper by Jack Dennis and Earl Van Horn (CACM vol 9, #3, pp 143-155, March 1966.)  Capabilities can be implemented in many ways including via hardware tags, cryptography, within a programming language (e.g.Java) or using protected address space.  For a introduction to capability-based mechanisms go here.  Linux uses protected address space and extended file attributes to implement capabilities.

A capability flag is an attribute of a capability.  There are three capability flags, named permitted (p), effective ]]> http://blog.fpmurphy.com/2009/05/linux-security-capabilities.html/feed 0