Does the security of RPC calls need to be configurable?

[chrisburr]

From the BiLDx meeting.

TODO: Add more description.

[marianne013]

Possibly. We have in the past made up "LogViewer" property which enabled users in a production group access to the pilot logs to do some debugging. Janusz is currently exploring if pilot logs in the new pilot logging system could be made available to site admins (which we might be able to extract from the GOCDB). I would foresee similar use cases in the future.

[chrisburr]

I think this kind of configuration would be useful to have in vanilla DIRAC as we have similar requests in LHCb to grant access to site admins information about their sites.

[chrisburr]

For LHCb: We have no need for this, though we do need to defined new properties for LHCb-specific systems in our extension.

[iueda]

new properties for LHCb-specific systems in our extension

Do you mean they need to be "configurable"? I suppose you mean just the new properties to be in the code, and not necessarily in the configuration?

[chrisburr]

I suppose you mean just the new properties to be in the code, and not necessarily in the configuration?

Yes, exactly this.

[iueda]

Belle II:
Not clear. We have the section in the CS, mostly untouched since the installation, but some were touched.
Some following https://github.com/DIRACGrid/DIRAC/wiki/DIRAC-v6r15#framework-changes
and others for some reasons (not yet clarified)
There are also some differences in the current DIRAC ConfigTemplate.cfg and our CS,
eg.

• https://github.com/DIRACGrid/DIRAC/blob/integration/src/DIRAC/ResourceStatusSystem/ConfigTemplate.cfg

  Publisher
  {
    Authorization
    {
      Default = Authenticated
    }
  

• Our CS:

        Publisher
        {
          Authorization
          {
            Default = all
            #@@-hideki@dirac_admin - 2014-06-04 22:10:52
            getDowntimes = all
  

The change of Default seems to come from DIRACGrid/DIRAC@5a6da62

So, I am not sure if everything works properly in our installation if we adapt all the Authorization in our CS to the ConfigTemplate.cfg

but I tend to agree that it is not good if such changes do not take effects due to the CS parameters made at the installation.

[andresailer]

I added this for the FileCatalog, so that only the few were allowed to modify MetadataFields, instead of everyone authenticated.

          Authorization
          {
            Default = authenticated
            deleteMetadataField = FileCatalogManagement
            addMetadataField = FileCatalogManagement
          }

I think being able to define this and similar things would be necessary.

[chrisburr]

My inclination here would be achive this with either:

• more granular properties in the code like FC_METADATA_MANAGEMENT
• options like GlobalJobMonitoring in the CS (i.e. GlobalMetadataManagement in this case)

I lean towards the first option as I think it's probably more discoverable and easier to manage for multi-VO (so each VO can define groups in their chosen way).