Storage of ACLs in file systems: platform overview (draft v1)

[James Buster]

On Oct 15, 10:22am, Robert Watson wrote:
} IRIX: Attributes
} 	XFS supports extended attributes on file system objects, so
} 	ACLs are stored there.  It wasn't clear to me from the white-
} 	paper on XFS that I found how rights to modify attributes are
} 	handled--the document suggested storing icons in attributes,
} 	which suggests direct user modification?  If it's only the
} 	owner, that's fine of course, but...

XFS supports two types of attributes: ROOT and USER. USER attributes
can be created and modified by the owner of the file and read by anybody
(if the permission bits allow). ROOT attributes can only be created or
modified by a trusted user and can only be read by trusted users. ROOT
and USER form separate namespaces, so the same name can be used for an
attribute in either namespace. As you can imagine, IRIX puts ACLs,
capability sets, and MAC labels in the ROOT namespace.

} 	Because I don't know much about attributes, I don't know about
} 	the efficiency concerns--because it sounds like it's user
} 	modifiable, it may be the case that one ACL is stored per
} 	file system object without checks for redundant storage.

One ACL is stored per filesystem object. ACLs aren't usually used enough
to care, and keeping a copy of every possible ACL just in case somebody
makes an identical ACL just isn't worth the programming effort or runtime
cost.

} For example, the disappearence of a MAC label from an object might be
} bad

That's what default MAC labels are for. In Trusted Irix, files without
MAC labels get the default MAC label, which gives it system high
sensitivity. It can't be read by anybody until the administrator gives
it a correct MAC label.

-- 
Planet Bog -- pools of toxic chemicals bubble under a choking
atomsphere of poisonous gases... but aside from that, it's not
much like Earth.
To Unsubscribe: send mail to majordomo at cyrus.watson.org
with "unsubscribe posix1e" in the body of the message