google/jimfs

Consider actual support for file permissions

cgdecker opened this issue · 7 comments

cgdecker commented

Saw a StackOverflow question about this.

It could be useful to have POSIX permissions for files in a file system actually affect behavior. For that to work, there'd also need to be some way to set a current user/group.

There are a variety of difficulties with this, though, such as:

  • Do we try to make this work for Windows-like file systems as well?
  • If there are other forms of authorization other file systems might use, is there some way to make this extensible so that a fake of one of those file systems can work properly?
  • Management of context (e.g. user/group for current thread or other context) seems pretty unrelated to the file system and as such isn't something I really wanted to do.
EdJoJob commented

Another solution could be to have an abstracted file view in which we can set a path to be either non-readable or non-writable or both. This would then be an interface that you could link the other permissions checking mechanisms through.

bbaldino commented

Don't suppose there's much chance this will end up getting done, is there? After not writing files to an actual filesystem, being able to test different permission scenarios in unit tests was the main reason I was looking for a virtual filesystem-type implementation, so I think this would be really useful. Even if only for the unix configuration.

  • 👍1
cgdecker commented

Yeah, I'm unlikely to work on this anytime soon. Partly just due to being busy with other things and largely because I haven't been particularly happy with any ideas I've had about how it should work.

I'd be more inclined to put in a mechanism by which individual files could be set unreadable or unwritable so that you can simulate "the current user is unable to read the file" manually (since it's a lot more straightforward and doesn't have to deal with anything about users or groups), but that doesn't help with a situation where you actually want to be testing posix permissions.

  • 👍2
bbaldino commented

Thanks for the reply @cgdecker. I actually can't even seem to get the attributes: Files.readAttributes(dir, PosixFileAttributes::class.java) gives me:

java.lang.UnsupportedOperationException: unsupported attributes type: interface java.nio.file.attribute.PosixFileAttributes

	at com.google.common.jimfs.AttributeService.readAttributes(AttributeService.java:378)
	at com.google.common.jimfs.JimfsFileStore.readAttributes(JimfsFileStore.java:214)
	at com.google.common.jimfs.FileSystemView.readAttributes(FileSystemView.java:774)
	at com.google.common.jimfs.JimfsFileSystemProvider.readAttributes(JimfsFileSystemProvider.java:346)
	at java.nio.file.Files.readAttributes(Files.java:1737)
	at org.jitsi.jibri.util.FileUtilsKtTest$1$1.invoke(FileUtilsKtTest.kt:52)

But I did end up finding https://github.com/marschall/memoryfilesystem which appears to support permissions, so I'm going to give that a shot.

cgdecker commented

@bbaldino Jimfs doesn't include a posix attribute view by default because for many common (testing) use cases, supporting it would just be unnecessary overhead. See the Configuration.unix() Javadoc for how to enable the full set of attribute views that you'd find on a Unix machine ("basic", "owner", "posix", "unix").

bbaldino commented

Thanks @cgdecker, totally missed that views had to be enabled.

maximebochon commented

I would be very interested in JimFS support for the following methods in a UNIX context: Files.isExecutable, Files.isReadable, Files.isWritable.

Since I use these methods in my unit tests, I had to replace JimFS with Marshall's memoryfilesystem. It looks like both projects are complementary on what feature is supported and what is not.

  • 👍2