NFSv4 ACL support in star

[Joerg Schilling]

Trying to add Andreas Grünbacher who implemented the original 
POSIX.1e code for Linux.

Tim Kientzle <kientzle at acm.org> wrote:

> CC: rwatson@ who implemented FreeBSD?s POSIX.1e ACL implementation
>
> CC: trasz@ who implemented FreeBSD?s NFSv4 ACL implementation
>
> CC: posix1e at freebsd.org, which has a number of security-minded
> people who might have suggestions here.

Thank you for adding these people. There is a need to come to an implementation 
that is useful for tar and I had already bad experiences with Sun/Solaris:

-	In 2005, Sun made the same mistake in the NFSv4 ACL implemenation as 
	they did in 1993 for the UFS ACLs: They did not add the numerical ID 
	in the text. Well, they added this later to libsec (and introduced
	ACL_APPEND_ID).

-	Some of the important interfaces from libsec are missing from sys/acl.h
	and only available to code that sits inside the Solaris source code and
	thus is able to #include <aclutils.h>. These interfaces include:

	acl_type()	that allows to find the ACL type in use behind the
			acl_t variable.

	acl_strerror()	that allows to translate ACL errors into text.

I like to see an implementation that (if implemented as an enhancement of the
withdrawn POSIX.1e ACL interfaces) gives similar features as libsec does:

-	libsec e.g. calls pathconf(name, _PC_ACL_ENABLED) in order to find
	the ACL type that is used for a file and controls which ACL flavor to 
	retrieve.

-	libsec includes code to deal with ephemeral IDs used with CIFS clients.

-	libsec offers acl_type(aclp) to find the ACl type without a need to
	call acl_totext(), so I could use:

	acl_totext(aclp, 0) for UFS ACLs and the known to work postprocess code.

	or

	acl_totext(aclp, ACL_COMPACT_FMT | ACL_APPEND_ID | ACL_SID_FMT) for
	NFSv4 ACLS.

See e.g.: http://schillix.berlios.de/man/man3sec/acl_totext.3sec.html
and other man pages at: 

	http://schillix.berlios.de/man/man3sec/

I am in hope that we could get a final library interface that still stays 
compatible between FreeBSD and Linux as this was the base for being able to 
support more platforms with POSIX.1e draft ACLs.


> > I am still wondering whether it is possible to implement an aproximation that 
> > could be better than not having a reverse conversion at all.
>
> I worry that approximation could be much worse than having no conversion at all.

I could think about a NFSv4 -> POSIX.1e draft conversion that only converts 
entries in the form:

	user:lisa:rwx-----------:-------:allow:502

as this is what you could definitely convert correctly.

> ACL conversions can create hidden latent security problems.

Such problems exist even if you use Win-DOS based CIFS clients as these clients 
sometimes reorder NFSv4 ACLs and thus cause a different behavior.

> At a minimum, any ACL conversion should produce obvious warnings.
>
> I?ve seen security experts worry even about conversions between
> NFSv4 and NTFS ACLs (which are almost identical).

See above, this has been discussed in the opensolaris mailing lists many years 
ago. The problems that have been discussed have been caused by reordering in a 
way that even violates the Microsoft documentation.

> That said, having good default translations from POSIX.1e
> to NFSv4 ACLs seems a necessity to help people migrate.
> But the reverse conversion seems very risky to me.

This is what I like to see, as I expect many people to migrate in the future.


> In addition to deny entries, NFSv4 ACLs also support ACL
> inheritance controls that are critical to preserving ACL
> intent and which cannot be represented in POSIX.1e.

Well, it seems that many people do not think about such problems as e.g. 
Solaris tar does not touch ACLs that might have been created via inheritance 
rules in case the related file does not include an own ACL entry in the archive.
>From my view, Solaris tar thus is a security risk.


> >> http://tools.ietf.org/id/draft-ietf-nfsv4-acl-mapping-03.txt
> >> 
> >> This did not stop the Linux NFSv4 server from doing it. To my knowledge,
> >> the Linux NFSv4 implementation does not properly preserve the semantics.
>
> Doing ACL conversion automatically at the filesystem or system call/libc
> layer is a really bad idea.
>
> Doing it in backup/restore utilities such as tar may be necessary
> to assist people in migrating.  Library support for that would certainly
> help.

Maybe the reason is that e.g. Linux did add POSIX.1e draft ACL support in 2001 
and NFSv4 ACLs did become the first approved platform spanning ACL standard 
in y2000 already.

On Solaris there was no problem with switching to a new ACL implementation when 
ZFS was introduced in y2005 to the public. The old UFS ACLs have been in use 
since 12 years already and people did know that they do not give you what you 
like.

On Linux, someone would have to decide to withdraw a recent implementation 
immediately after it was introduced....

> I?m not familiar with the Linux NFSv4 server:  Are there
> cases where the ACLs that you set are not the ACLs that
> actually get enforced?  That would be very, very bad.

On Solaris, the NFSv4 server does not expose ACLs unless the underlying 
filesystem implements NFSv4 ACLs.

> >> With that being said, you will likely need to handle NFSv4 ACLs and
> >> POSIX ACLs independently. Since only 1 ACL implementation is active at a
> >> time, you could probably have a bit to indicate which of the two is used.
>
> Yes.  All of the tar ACL extensions currently store a single type
> of ACL and mark which kind it is.

This is why star adds SCHILY.acl.ace= entries for NFSv4 ACLs.

I am ready with the final conversions that hopefully will allow the code to 
compile again on Linux tomorrow. Maybe, I should publish the source then as a 
base for future discussions.

Jörg

-- 
 EMail:joerg at schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js at cs.tu-berlin.de                (uni)  
       joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily