NFSv4 ACL support in star

Tim Kientzle kientzle at acm.org
Wed Nov 6 15:30:59 UTC 2013


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.


On Nov 5, 2013, at 6:51 AM, Joerg Schilling <Joerg.Schilling at fokus.fraunhofer.de> wrote:

> Richard Yao <ryao at gentoo.org> wrote:
> 
>>> BTW: I expect a local ACL implementation (as Solaris does) to be able to
>>> auto-convert POSIX draft ACLs into NFSv4 ACLs and it would be nice if we
>>> did find a way to do the converse soon.
>> 
>> The converse is widely considered to be impossible:
>> 
>> "Since NFSv4 ACLs are more fine-grained than POSIX ACLs, it is not
>> possible in general to map an arbitrary NFSv4 ACL to a POSIX ACL with
>> the same semantics."
> 
> Well, I know that one reason for withdrawing the POSIX ACL draft in October 
> 1997 was that the POSIX draft was too simple and did not implement what people 
> like to see.
> 
> 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.

ACL conversions can create hidden latent security problems.

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).

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.


> I would expect that an NFSv4 ACL that does not make use from deny type entries 
> and that does not use the other permissions from NFSv4 ACLs should have a good 
> chance for a not too bad conversion. Maybe this kind of conversion could be 
> made optional via a star command line switch….

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.


> 
>> 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.

>> i.e. There are situations where the NFSv4 ACLs that you get back from
>> the Linux NFSv4 server do not match what you set.

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.


> I was asking in hope to get knowledge whether there is a free implementation 
> for this kind of conversion.
> 
>>> I selected ACL_COMPACT_FMT as it tends to create slightly shorter strings.
>>> 
>>> Are there any objections or forseeable problems for the future?
>> 
>> You might want to read the link that I provided above.
> 
> Did you see problems mentioned in that ietf paper?
> I just die a coarse read during last weekend so far...
> 
> 
>> I don't know of any library that does what you want. There was an
>> extension of NFSv4 ACLs called Richacls that attempted two combine the
>> two ACL implementations. However, conversion only worked one way:
>> 
>> http://www.bestbits.at/richacl/
>> 
>> 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.

Hopefully, none of them will be silly enough to write a translated
ACL into an archive.  (Someone will think of it; worse, someone will
suggest storing both the original and the translated version.  Ugh.)


> Are you talking about Linux here?
> 
> Given the fact that FreeBSD and Linux did implement a sufficiently identical 
> library for POSIX draft ACLs in the past, I am in hope, we could arrange the 
> same for NFSv4 ACLs. So it would be nice if platforms besides Solaris did 
> either pick up the libsec interface for both POSIX draft ACLs and NFSv4 ACLs or 
> implement a compatible enhenced version of their previous POSIX draft ACL 
> library.
> 
> BTW: I tried to contact Andreas before but did not get a reply yet.
> 
> For the POSIX draft -> NFSv4 conversion, people could use the code from 
> OpenSolaris libsec:
> 
> 
> http://hg.berlios.de/repos/schillix-on/file/2f5a0fb0368d/usr/src/lib/libsec

Thanks for that pointer.  We should all certainly take a look
at that.  Having consistent translations on multiple platforms
would certainly help.

Cheers,

Tim



More information about the posix1e mailing list