Github user huozhanfeng commented on the pull request:

    https://github.com/apache/spark/pull/2320#issuecomment-55102455
  
    @pwendell @tgravescs Thanks for your advice. 
    
    Yes I want to support multiple users all using different credentials and in 
our application scenario users can't access their keytab each other. In my 
opinion, the spark administrator is responsible for producing and placing 
kerberos keytab file to the spark client, for example set 
"/home/tim/.tim_spark.keytab" with permission "400"  and  config param 
"_HOST/._USER_spark.keytab"  in spark-defaults.conf, so it can be transparent 
to the spark user. I don't think we need to care about the scene that one user 
can use the keytab of another for this is another thing.
    
    Read the keytab operation occurred in the process of the driver to create 
SparkContext instance. So it has nothing to do with whom start the spark 
daemons but with whom start the driver.
    
    As for document and letting the feature not to run in yarn mode, I will do 
it recently.
    
    The most important is how to distribute the token file security and there 
are two feasible method.
    
    1:Extending HTTP file server interface to enable user to share files with a 
secret(set secret in a conf file on all of the worker nodes or other way) to 
authenticate this HTTP request, for example "def addFile(path: String , 
isSecret boolean)".  We need such common functions in the long run.
    
    2:Only encrypt token file before distributing it, and executor decode token 
file before using it. 
    
    I don't know which is more suitable. Or there are other better design?



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to