Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

usernames and permissions on create are ... pretty minimal #5

Open
convolvatron opened this issue Dec 5, 2017 · 4 comments
Open

usernames and permissions on create are ... pretty minimal #5

convolvatron opened this issue Dec 5, 2017 · 4 comments

Comments

@convolvatron
Copy link
Collaborator

No description provided.

@jssmith
Copy link
Owner

jssmith commented Dec 8, 2017

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

@convolvatron
Copy link
Collaborator Author

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
Copy link
Owner

jssmith commented Dec 8, 2017

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
Copy link
Collaborator Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants