>> [non-ACL-aware kernel meets ACLed filesystem]
> Normally, you do not want a system to access a volume which it
> doesn't understand - we don't want, say, 4.2BSD systems to access
> long uid/gid filesystems, either - because even if it doesn't corrupt
> ACLs, it might give away access rights that were not intended.

The corruption argument is a valid one; we should make sure that either
no corruption occurs except explicitly (eg, the file-in-fs-root
technique, such as is used for quotas) or the non-ACL-aware kernel
knows it can't do a thing with the filesystem.

However, the "might give away access rights that were not intended"
argument is, I think, specious; when you move disks between kernels, or
boot alternative kernels, you are always risking this.  Suppose the
target machine has mode 644 disk devices, to pick a simple example.

>> and also a non-acl ffs be used on a system with an acl aware kernel,
>> which does not cause the addition of acl features to the filesystem
>> but is still useable by that acl aware system, just sans acls.
> Thats fine - and actually, it would be very hard to avoid this
> property.

I don't see why; you could configure a kernel with
	file-system     ACLFFS
	#file-system    FFS
and get exactly that.  (Of course, this would depend on ACLs being
added in this way, but I don't see why that couldn't be done.)

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B