Allow chmod to set S3 ACLs.

[skorokithakis]

From what I understand, riofs doesn't currently set ACLs, which is a core part of my S3 use case. It would be good if the POSIX ugo attributes were mapped to the S3 owner, authenticated user, everyone groups, so we could do chmod r+o myfile to make the file world-readable.

[henningpeters]

I am not convinced that this is a good idea. As much as I see this as a neat feature, it is not what a user might expect when he issues a chmod on a seemingly local filesystem.

[skorokithakis]

Well, by that logic, one shouldn't expect the S3 file to change when writing to a seemingly local filesystem :) Is there another way to set ACLs at the moment?

[henningpeters]

No, there is no feature in RioFS to change S3 ACL. RioFS is primarily intended to be used as an interface to S3 for legacy applications that require a POSIX-like filesystem. It is not intended as API alternative to the S3 API as it is a leaky abstraction. Therefore, I think adding features that would surprise legacy applications is not within the scope of RioFS.

[darrencruse]

Hi forgive me for commenting on a closed issue but I too feel like I need this feature I'm hoping somebody can advise me if I'm missing something...

To clarify: ours is a "legacy application" which is basically a large amount of html and php (along with sym links unfortunately) that we're needing to migrate off of some old servers and onto amazon s3. The way we're headed is everything both the html and the php is getting transferred into s3, with the html getting served directly from s3 while the php is served off ec2 instances that would see the php files as if they're local, thanks to riofs.

In our case all these legacy html and php files do have users/groups/permissons assigned that must be retained (in some fashion) in the new system. e.g. we have different editorial groups that have corresponding unix groups to limit their write permissions to just those files they're responsible for (even though they may have read permissions for most everything else).

Because our content has sym links (which we're hopeful riofs might be enhanced to support like s3fs does), we can't load our content directly into S3. Instead we'll need to load our files via riofs so that it has the opportunity to create the simulated sym link objects in S3. So we'd be copying the files into riofs, untarring files into riofs, using rsync into riofs, etc.

In these cases we'd need the permissions currently on the files to flow through riofs and onto the files ("objects") in S3. i.e. I can't think of any alternative way to getting the permissions correct in S3 unless riofs is trying to set them as it's creating the copied in files?

Am I missing something?

[wizzard]

If this feature is requested by RioFS users we could store (and load) files and directories permissions in S3 custom headers. And make this feature optional (disabled by the default).

[darrencruse]

Thanks Wizzard. I wonder now if I was oversimplifying. I was thinking/hoping we might create our same unix users and groups in S3 and be able to truly have the S3 object permissions one for one (maybe reflected onto the rio cache file permissions?) But maybe it's not so simple.

Update: I just learned things are harder than I'd hoped - it doesn't look like you could easily map unix user/group permissions to S3 ACLs. I guess this is what henningpeters and wizzard understood that was going over my head. Don't mean to flood the issues list but in case it's helpful for others...

Details here:
http://docs.aws.amazon.com/AmazonS3/latest/dev/acl-overview.html#SpecifyingGrantee

Note in particular:
"When using ACLs, a grantee can be an AWS account or one of the predefined Amazon S3 groups. However, the grantee cannot be an Identity and Access Management (IAM) user. "

Where in the above the "predefined Amazon S3 Groups" would not map easily to unix groups (unless people constrained their unix groups to a special set of groups designed to correspond to the amazon "Authenticated Users", "All Users", "Log Delivery" S3 groups?).

And then the AWS account names (at least in my case) would not easily map to our unix users (I was thinking making IAM users corresponding to our unix users might be doable, but creating AWS accounts corresponding to each user doesn't seem doable).

So I guess I understand a little better why riofs can't have simple user/group permission handling but I guess I'm a little confused - are people instead managing their permissions directly through e.g. Amazon AWS Console or Amazon's S3 apis instead of thru riofs?