This ticket is a duplicate of https://pagure.io/taskotron/issue/184

This ticket also depends on https://pagure.io/taskotron/issue/187

This ticket had assigned some Differential requests:
D848
D882

One of the big blockers here is that we have some 777 dirs in the package. When we submitted testcloud for review, that was a problem and I expect that it would be a problem if we were to submit the current specfile.

Two ways to solve this come to mind:

1. Create a taskotron POSIX group and restrict write/execute on the 777 dirs to that group, removing global write/execute

2. Rework bits of libtaskotron such that it tries to write to the global directories but if that fails, create some directory (/home/<user>/taskotron/ or /tmp/taskotron/ maybe?) to use as a new base.

I think that 2 would be easier for folks to handle but that's some complexity that I'd rather not deal with. 1 is far simpler but would still require some code checking for group membership when the run starts and error handling if there's no write access.

Thoughts on how to handle this?

! In #779#10847, @tflink wrote:
One of the big blockers here is that we have some 777 dirs in the package. When we submitted testcloud for review, that was a problem and I expect that it would be a problem if we were to submit the current specfile.

Two ways to solve this come to mind:

1. Create a taskotron POSIX group and restrict write/execute on the 777 dirs to that group, removing global write/execute

2. Rework bits of libtaskotron such that it tries to write to the global directories but if that fails, create some directory (/home/<user>/taskotron/ or /tmp/taskotron/ maybe?) to use as a new base.

I think that 2 would be easier for folks to handle but that's some complexity that I'd rather not deal with. 1 is far simpler but would still require some code checking for group membership when the run starts and error handling if there's no write access.

Thoughts on how to handle this?

I am for 1 which is more standard, cleaner and less work. Also I think it's the way we solved the same issue in testcloud, right? So unless someone has another proposal besides 1 and 2, I vote for 1.

Yeah, 1 is how we solved the problem for testcloud. While I'd really like to remove as many barriers to running tasks as possible, I'm not convinced that 2 is worth the effort in development and debugging, either.

Package sent for review - https://bugzilla.redhat.com/show_bug.cgi?id=1344249

libtaskotron update is in bodhi, closing.