Kurtis Heimerl wrote:
Sounds like a reasonable thing. There's one problem here, that being that
each user will require their own config file.
That's not needed. The Configuration is a set of properties. We can
add a method FileSystem.getUsername(Configuration) that first looks in
the configuration, and, if nothing is found, defaults to the environment
variable. Then FileSystem implementations can call this. JobClient
should call FileSystem.setUsername() before submitting a job. So it's
not normally in a config file, but is in the Configuration.
There's accountability, but not great protection. If someone put their
client into kerberos and it was accepted, they could take any role they
wanted.
I'm not sure what you mean. The server would need to validate the
kerberos ticket with the kerberos server to check that users really are
who they say they are.
I think groups and root are easy, so I plan to implement those initially as
well. Is there any more reasonable way to do root than just hardcoding that
root can do anything? I thought about adding root to all groups, but
there's
a chance that a file had no groups. I guess I could add one root group that
simply contains root. That would allow the service to allow others to
run as
root as well.
I think we should not try to re-invent too much, but mostly trust that
the unix model is workable. In unix, root can do anything. I think we
need that capability and should implement it similarly.
Doug
