RFR 8213031: (zipfs) Add support for POSIX file permissions

[Langer, Christoph]

Hi Alan, all,

here comes the next proposal for POSIX support in jdk.zipfs - which hopefully represents the converged solution, at least in its overall design.

http://cr.openjdk.java.net/~clanger/webrevs/8213031.6/

With that patch, the behavior is the following:
a) A ZipFileSystem instance by default does NOT support the PosixFileAttributeView. However, it is possible to query for a known attribute named "zip:storedPermissions". Its value can be null to represent no  permission information or any set of PosixFileAttribute.
b) A ZipFileSystem instance can be created with the property "posix"=true. In that case, PosixFileAttributeView is supported with default values.
	-> owner: A UserPrincipal with the name of System.getProperty("user.name") if property access is allowed, "<zipfs_default>" otherwise
	-> group: A GroupPrincipal with the name "<zipfs_default>".
	-> permissions: Set.of(OWNER_READ, OWNER_WRITE, GROUP_READ)

	The default values can be modified by using the properties "defaultOwner", "defaultGroup" and "defaultPermissions".

Implementation wise the ZipFileAttributeView always extends PosixFileAttributeView but behaves different, depending on how it was obtained.

Within ZipFileSystem, the Entry inner class is not static any more but always has a reference to the Enclosing ZipFileSystem. That's needed because default owner/group/permission can be set on ZipFileSystem instance level now and the Entry, implementing the FileAttributes needs to know where it belongs to. This seems somewhat logical anyway.

The new test "TestPosix" is quite extensive. I had to add 2 permissions to test.policy to allow testing in a restricted environment.

Module-info and CSR have been adopted, too.

Thanks in advance for reviewing.

Best regards
Christoph

> -----Original Message-----
> From: Langer, Christoph
> Sent: Montag, 21. Januar 2019 10:17
> To: 'Alan Bateman' <Alan.Bateman at oracle.com>
> Cc: nio-dev <nio-dev at openjdk.java.net>; OpenJDK Dev list <security-
> dev at openjdk.java.net>; Java Core Libs <core-libs-dev at openjdk.java.net>;
> Volker Simonis <volker.simonis at gmail.com>
> Subject: RE: RFR 8213031: (zipfs) Add support for POSIX file permissions
> 
> Hi Alan,
> 
> first of all, thank you for your input on this.
> 
> > I think the approach to explore are:
> >
> > 1. zipfs supports PosixFileAttributeView without subsetting. If
> > readAttribute(file, BasicFileAttributes.class) succeeds then
> > readAttribute(file, PosixFileAttributes.class) should also succeed, even
> > if there aren't permissions encoded in the zip entry's external file
> > attributes. It would mean that owner and group return default values,
> > and permissions may return a default value. It does mean you can't
> > distinguish the default value from "no permissions" but there is
> > precedence for that, e.g. mount a FAT32 file system on Linux or Unix
> > systems and `stat` a file to have the stat structure populated with
> > default uid, gid and mode bits.
> 
> OK, I can see the point that in a PosixFileAttributeView as it is, there's no
> place for optionality/null values. However, with this approach the benefits
> would be that Files::get/setPosixPermissions would work and that's why I
> think we should pursue this. The challenge will be to find reasonable
> defaults.
> 
> > 2. zipfs defines a new FileAttributeView that defines read and write
> > access to permissions stored in a zip entry's external file attribute.
> > As it's a new view then it can define the behavior for the case that the
> > zip entry doesn't have permissions. Furthermore it does not need to
> > extend BasicFileAttributeView so doesn't need to be concerned with bulk
> > access, nor concerned with group/owner. As you know, the attributes API
> > allows for both type safe and dynamic access so you have a choice as to
> > whether to support both or just dynamic access. With the first then
> > jdk.zipfs would export a package with a public interface that defines
> > the view. If someone wants type safe access to the permissions attribute
> > then you need to import the class. The alternative is to not export any
> > packages but just define the view in the module-info. The view its name
> > and define the name/type of the permissions attribute, it will also
> > define how it behaves when the external attributes aren't populated. In
> > usage terms it means reading the permissions will be something like
> > Files.readAttribute(file, "zip:permissions") and casting the value to
> > Set<PosixFilePermission> - not pretty but it avoids depending on a
> > JDK-specific API.
> 
> For this approach, there are 2 things I dislike. The first is that I don't think we
> should export named packages from module jdk.zipfs that people would
> develop Java code against while not being in the Java API. And secondly, this
> way would not support using Files::set/getPosixPermissions since the
> specification/implementation of that utility method explicitly refers to
> PosixFileAttributeView.
> 
> I can imagine something like this:
> Zipfs by default implements an own view that offers dynamic, not type safe
> access to "zip:permissions" and we'll document this. If a user of zipfs wants
> to see full PosixFileAttributeView support with default values, then we
> should allow for a creation attribute for the zipfs that can control this. Maybe
> we can even allow specifying default values for user, group and permissions
> via zipfs attributes.
> 
> I'll work to develop the patch into this direction unless you tell me that this
> idea is bogus (if so, then I hope it be soon 😊)
> 
> Thanks
> Christoph
> 
>