usernames and permissions on create are ... pretty minimal

[jssmith]

What steps do you recommend to resolve this issue? Can we take the user/group from the client process.

[convolvatron]

the whole unix user id in a distributed context has always been a bit crap (they used to have you use a fragile and very insecure login roc facility called yellowpages to ensure the ids were meaningful across the organization)

i'm a little concerned that in lambda-land, or really any other context than single machine they also might be meaningless.

what I'd like* to do is have this kind of policy stuff done in free-form dictionaries. that would allow us to mix together:

• nfs implementation defaults
• user overrides
• wholesale from 'somewhere else', maybe even the filesystem itself

if we did that then user id, group, default permissions mask, etc for the single machine unix case would just be another policy blob

[jssmith]

Ok, I'm convinced that using the Unix user id from the process is a bad idea and I think we should make the application configure it.

What I was aiming for was to get it to work “out of the box,” so one could just open a database and get the expected permissions. Unfortunately, even the most popular EC2 AMIs use different ids for their default users, so it seems pretty much like a lost cause. It will be easiest for the application to provide them, and in the case that they come from somewhere else the application can wire this up.

[convolvatron]

think of it as an extension of avoiding node-local state

the only real conflict is when someone using /efs and umask is trying to interact.

more generally unix permissions are pretty irrelevant, and ideally the sqlite instance should be authenticating with the fileserver (and not just general host level access like with efs)

from that perspective a default user 'the user' and a 0666 default mask is probably the right choice...but from the more general library perspective, being able to configure it get it from the local environment would be nice