Subject: Re: UFS1 extended attributes
To: Martin Husemann <>
From: None <>
List: tech-kern
Date: 01/14/2003 03:59:35
At Mon, 13 Jan 2003 18:40:49 +0100,
Martin Husemann wrote:
> On Tue, Jan 14, 2003 at 02:19:32AM +0900, wrote:
> > I made a patch to port "Extended Attributes for UFS1" from FreeBSD and
> > OpenBSD.
> Can you give a short summary what this is about?
> Martin

Extended attributes permits sets of arbitrary (name, value) pairs to be
associated with files and directories. For example,

- you can set message digest to kernel with these commands

# setextattr system md5 `md5 -q /boot/kernel/kernel` /boot/kernel/kernel

- filemanager application can associate icon image with each files
- When a MUA uses MH style mail folder, the MUA can store mail subject
  in extended attributes.

Extended attributes is developed in TrustedBSD project(http://www.trustedbs=,=20
because "access control lists", "capability sets" and "mandatory access
control blocks" should be persistently associated with files and directorie=
s to
support trusted features.

=46rom README.extattr(this is not included in diff)

  About UFS Extended Attributes

Extended attributes allow the association of additional arbitrary
meta-data with files and directories.  Extended attributes are defined in
the form name=3Dvalue, where name is an nul-terminated string in the style
of a filename, and value is a binary blob of zero or more bytes. The UFS
extended attribute service layers support for extended attributes onto a
backing file, in the style of the quota implementation, meaning that it
requires no underlying format changes in the filesystem.  This design
choice exchanges simplicity, usability and easy deployment for
performance.  When defined, extended attribute names exist in a series of
disjoint namespaces: currently, two namespaces are defined:
distinction lies in the protection model: USER EAs are protected using the
normal inode protections, whereas SYSTEM EAs require privilege to access
or modify.

// Hiramatsu, Yoshifumi