Owner of job changes to last edited user -- is this a bug?

[Carey Rogers]

Hello,

I've noticed some behavior related to job ownership and I'm curious if this is intended. Here is the scenario:

We have system maintenance jobs that run on a cron schedule in Rundeck. For example, a job that runs every 30 minutes to checkout the latest version of some files from our SCM system. These jobs were created by user "admin" who has all permissions as defined in the default admin.aclpolicy file.

Everything works great with these jobs until someone other than "admin" edits the job. It appears when another user with appropriate permissions edits the job (for example, user "restricted-admin"), the job becomes associated with "restricted-admin". This is not a problem until "restricted-admin" leaves the company and his permissions are taken away. At that point, the job runs start to fail because the appropriate permissions to run the job are no longer associated with the user that owns the job.

I understand that I can restrict the users who can edit a job via aclpolicy, but it still seems odd that job ownership would change based on last edit. There is no mention of job ownership in any documentation that I can find.

Is this intended behavior or a defect?

Thanks,
Carey

[virgil.c...@gmx.net]

Hello!
I am not sure but I presume that is not such thing as "job ownership"; what is actually happening is the fact that once the job is scheduled, it is using the user who last time scheduled the job.
And Rundeck can't tell the difference between a user that edit the job and the one that first time scheduled the job.
Rundeck developers may answer this question better than me and maybe provide a fix: use for scheduling the user who first added the scheduling setting to the job.

Virgil

[Greg Schueler]

Hi,

There is not really an "owner" of a job, but the user who last modified the job is stored, and that user name and their authorization roles are used when the scheduled job is executed so that the execution has only the permissions granted to that user.

If you specifically grant authorization by username in aclpolicy files, and later remove those authorizations, you could be have the state where the scheduled job would fail due to lack of authorization. Granting authorization via roles should not have that problem.

--
Greg Schueler

--
You received this message because you are subscribed to the Google Groups "rundeck-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rundeck-discu...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.