Users unable to delete files that they own unless they also own the trash directory about marfs

[jti-lanl]

The trash scatter-tree dirs should probably just be world-writable. Fuse won't let anyone see them directly, and the MD FS will be hidden from view on the interactive nodes.

For ease-of-use outside LANL, we should have admins create the top-level dir with the whatever ownership/access is desired, such that all users in the relevant namespaces will be able to create files there. (This is not something we can guess.) Then when fuse generates the "scatter tree" below that, it should just perpetuate those features to the subdirs.

[jti-lanl]

Added comments to the Install Doc.

[brettkettering]

Please determine what the ownership of the trash should be. Document that in the design document in the Documentation folder.

[jti-lanl]

What came out of our meeting a few days ago was that the bottom level of the tree should be world-writable, not-listable, not readable. (So, maybe chown root:root, chmod 702 ?) Files written to the trash should be chmod'ed to make them readable only by the owner. (So, maybe chmod 400.)

[atorrez]

Jeff and I talked about this and tried a few experiments. Based on some initial experimentation, the upper level (and subsequent) directory could be set to 701 permissions with the lowest level directory set to 703. A user can create a file in the lowest level but cannot list the directory. The user can list (ls) the file if they know the full path and filename. One potential issue is the the user can change permissions of the file (to write or executable) which could lead to other non-desirable consequences.

Note the top level directory world execute permission must be set (701) in order for the user to create and/or list (ls) the file.

[brettkettering]

In order to mess this up one would have to have access to the underlying GPFS metadata file system. MarFS prevents this without escalating to root.

We need to have the admins set the permissions as necessary to enforce the functionality we want.

Only need to revisit this if we have to use FUSE mount directly on interactive FTA and it is exposed to a user if the FUSE mount crashes.