ACL and CronJob


#1

Hello,

I am trying to run a CronJob who’s function is calling a method from a Type constrained by AclPrivilege.
The issue is that the user Authorizer used by the CronJob does not meet the ACL conditions, hence:

in request_json raise e urllib2.HTTPError: HTTP Error 401: Unauthorized from action Site.getVariablesPartition from env_server.js

I looked in the documentation hoping to find a way to impersonate or assign a AdminGroup to the CronJob without success. I am working on version 7.6.1.

Thoughts ?


#2

It doesn’t appear to be acl (authorizer doesn’t apply acls on fetch). The error looks like it is authorization of the action itself. @garnaiz Does cron need to use C3.asWorker() to invoke the action? I’m not sure why that would be necessary.


#3

From the error message, this doesn’t look like a c3 platform authorization issue either.
The http 401 means that whatever request to an http endpoint is not authenticated. What is the implementation of Site.getVariablesPartition()? It looks like it is trying to invoke some external endpoint.


#4

@garnaiz That explains it. We added something for BatchJob/MapReduce to allow the jobs to run as the user that initiated them for a similar issue. I don’t think that would work here however, since there is no real “user” associated with running a cron job. It is defined in seed data and has no choice but to be run by authorizer.

@wdouhard I’m not sure what we could do about this. We can’t pull a user out of thin air when running the job.
@DavidT Any ideas? Can they use config/secrets to store credentials that their action would then use? Something else?


#5

@trothwein I would assume that “Authorizer” should ignore ACLs (just like SystemAdmin)


#6

@rileysiebel I see you didn’t read my initial reply to this :slight_smile:


#7

@wdouhard we do need more details what Site.getVariablesPartition implements

@trothwein depending on above yes we can use config for configuring action credentials or Cron can be extended to allow “runAsUser” attribute


#8

Thank you for all your contributions !

Site.getVariablesPartition implementation is customer code so I am not allowed to share it here.
Basically it is some python code that calls other python function from the same file without making any calls to a third party.

I will send @garnaiz @trothwein @rileysiebel @DavidT an email attaching the implementation.

I understand this does not look like a trivial issue so I am also going to start looking for a different approach.


#9

@wdouhard So what “user” should the Site.getVariablesPartition be called as to make it work properly?


#10

Being able to choose would be nice but I understand it comes with security vulnerabilities.

I also remembered I used to encounter 401 errors when making calls to python functions from a worker context. It is a known issue. Maybe Authorizer is supposed to be allowed to make the call but this bug happens.


#11

@wdouhard We can add the ability to run the job as a user that is known at time of deployment. In reality, who really is the user? For batch/mapr we have a “runAsUser” option where the user who started the job is the user that the child actions are run as. That won’t work here since no user initiates a run of a cron job.


#12

@trothwein maybe CronJob can grow a “Role” field instead of a “User” field? That would eliminate the need to actually create a user after provisioning the tag?


#13

@rileysiebel @DavidT I believe I would need to call C3.asUser() internally for this. I don’t believe we can dispatch as a role.


#14

I confirm that my interpretation was wrong about this issue.
There is a bug in 7.6 that causes c3 calls from a python function in a worker context to always return a 401 error. This is already documented and is being addressed.
That being said it still might be useful to be able to give a Role or a User context to a CronJob.
Thank you again guys !