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

Authorized users in security.pp #94

Open
ccnifo opened this issue Jul 16, 2018 · 3 comments
Open

Authorized users in security.pp #94

ccnifo opened this issue Jul 16, 2018 · 3 comments

Comments

@ccnifo
Copy link
Collaborator

ccnifo commented Jul 16, 2018

security.pp includes authorizations for user condor_pool, but this user is supposed to exist only if password auth is used: could we condition it to use_password_auth = true ?

Meanwhile, replacing the default machine_list_prefix by condor@$(UID_DOMAIN)/ (instead of condor_pool@$(UID_DOMAIN)/) would be interesting for configs using root as condor_user:
I can be wrong, but I think you still need another user than root@domain to be authorized, the most obvious one is condor@domain.

I can propose commits to do this. However, this would be a change with a strong impact on the default configurations.

@kreczko
Copy link
Member

kreczko commented Jul 16, 2018

security.pp includes authorizations for user condor_pool, but this user is supposed to exist only if password auth is used: could we condition it to use_password_auth = true ?

Absolutely.

Meanwhile, replacing the default machine_list_prefix by condor@$(UID_DOMAIN)/ (instead of condor_pool@$(UID_DOMAIN)/) would be interesting for configs using root as condor_user:
I can be wrong, but I think you still need another user than root@domain to be authorized, the most obvious one is condor@domain.

Hmm..that's interesting, cannot say I've tried it. It is definitely not a trivial config

  • condor_user: condor → root
  • machine_list_refix: condor_pool → condor
    That's what you're suggesting here, right?

I can propose commits to do this. However, this would be a change with a strong impact on the default configurations.

If you preserve the default behaviour, this should be fine.

@ccnifo
Copy link
Collaborator Author

ccnifo commented Jul 17, 2018

Hmm..that's interesting, cannot say I've tried it. It is definitely not a trivial config

condor_user: condor → root
machine_list_refix: condor_pool → condor
That's what you're suggesting here, right?

What I propose precisely, is:

  • $machine_prefix_remote = condor@$(UID_DOMAIN)/
  • leaving condor_user, it's fine (but it's already root in init.pp, and I'm not sure it can be changed).
  • adding in security.pp something like:
if $use_password_auth {

  $machine_prefix_password = condor_pool@$(UID_DOMAIN)/
  $manager_list_password   = prefix($managers, $machine_prefix_password)
  $manager_list            = union($manager_list_local,
  $manager_list_remote,
  $manager_list_password)
  #scheduler_list, worker_list defined in the same way

} else {

  $manager_list            = union($manager_list_local,
  $manager_list_remote)
}
  • adding in the template conditionals around each condor_pool occurence, like:
ALLOW_ADMINISTRATOR = root@$(UID_DOMAIN)/$(IP_ADDRESS), <% if @use_password_auth then -%>condor_pool@$(UID_DOMAIN)/$(IP_ADDRESS)<% end -%>, $(CMS)

If you preserve the default behaviour, this should be fine.

That's the problem : a user not having set use_password_auth will get changes in his authorization files (condor_pool disappearance).

@ccnifo
Copy link
Collaborator Author

ccnifo commented Aug 24, 2018

If you preserve the default behaviour, this should be fine.

That's the problem : a user not having set use_password_auth will get changes in his authorization files (condor_pool disappearance).

I just noticed that use_password_auth is enabled in the default configuration; thus I think these changes can be quite seamless, it would only impact those who disabled it.

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