Support for parallel paludis operations

[chaoflow]

As far as possible, paludis should support the parallel run of multiple paludis operations. Where not possible, paludis should prevent it. As long as paludis does not prevent it, there should be a FAQ.

Portage implements some checks and seems to support parallel runs. Whereas I don't know how effective portage's mechanism is, user's migrating from portage are used to be allowed to run multiple emerge instances. This should be at least addressed in an FAQ.

short term: locking could be realized via hooks. In case another paludis is already running, paludis would simply be aborted giving a corresponding error message.

long term: real parallelisation

[ciaranm]

No. Locking the way Portage does it is a) silly and b) a security hole. Paludis won't support inter-process locking.

Parallelism is an entirely different issue. When Paludis does parallelism it will be with a single control process and internal locking.

[chaoflow]

Replying to ciaranm:

No. Locking the way Portage does it is a) silly and b) a security hole. Paludis won't support inter-process locking. Parallelism is an entirely different issue. When Paludis does parallelism it will be with a single control process and internal locking.

Sounds perfectly sane. What about preventing parallel paludis runs or at least a FAQ or some other way of explicitly telling people, that parallel paludis operations are not supported?

[ciaranm]

Replying to chaoflow:

Sounds perfectly sane. What about preventing parallel paludis runs or at least a FAQ or some other way of explicitly telling people, that parallel paludis operations are not supported?

Preventing parallel runs is a security hole. And an FAQ entry is pointless -- parallel executions are fine so long as they stick to certain operations.

[chaoflow]

Replying to ciaranm:

Preventing parallel runs is a security hole.

could you elaborate on that?

And an FAQ entry is pointless -- parallel executions are fine so long as they stick to certain operations.

Wouldn't it be nice to have documented, which operations are fine for parallel execution?

[ciaranm]

Replying to chaoflow:

Replying to ciaranm:

Preventing parallel runs is a security hole.

could you elaborate on that?

It's an inversion. A non-root user can obtain the locks and prevent root from being able to do anything for an arbitrarily long time.

And an FAQ entry is pointless -- parallel executions are fine so long as they stick to certain operations.

Wouldn't it be nice to have documented, which operations are fine for parallel execution?

Not really. If you don't already know, you shouldn't be doing it at all.

[chaoflow]

Replying to ciaranm:

Replying to chaoflow:

Replying to ciaranm:

Preventing parallel runs is a security hole.

could you elaborate on that?

It's an inversion. A non-root user can obtain the locks and prevent root from being able to do anything for an arbitrarily long time.

That would not be a security hole, but at most a denial of service, which can easily be prevented by file system permissions. Operations unsafe for parallel execution anyway need special privileges for their operation, otherwise every paludis system would be vulnerable to the DoS right now. So, using the mechanism used to prevent a normal user from merging a package can be used to protect a normal using from creating lockfiles, that could annoy root.

And an FAQ entry is pointless -- parallel executions are fine so long as they stick to certain operations.

Wouldn't it be nice to have documented, which operations are fine for parallel execution?

Not really. If you don't already know, you shouldn't be doing it at all.

Well, at the very least that should be in the FAQ:

Q: May I run multiple paludis operations in parallel? A: Not really. If you don't already know, you shouldn't be doing it at all.

That would give users the wrong impression, that paludis developers don't value them, but they at least would know, that they shouldn't run multiple paludis in parallel.

Of course way better would be a table listing operations that are safe to combine.

And way way better would be some simple locking inside of paludis preventing bad things from happening.

[ciaranm]

Replying to chaoflow:

That would not be a security hole, but at most a denial of service, which can easily be prevented by file system permissions. Operations unsafe for parallel execution anyway need special privileges for their operation, otherwise every paludis system would be vulnerable to the DoS right now. So, using the mechanism used to prevent a normal user from merging a package can be used to protect a normal using from creating lockfiles, that could annoy root.

Huh. Wrong.

Well, at the very least that should be in the FAQ: Q: May I run multiple paludis operations in parallel? A: Not really. If you don't already know, you shouldn't be doing it at all.

No it shouldn't.

And way way better would be some simple locking inside of paludis preventing bad things from happening.

Paludis is not there to protect you from yourself.

[cwells]

I am so very glad I saw this ticket. I almost made the mistake of using this software. Anyone who thinks it's beneath them to put something in a FAQ that can save a few people some pain shouldn't be writing software for public consumption.

Thanks!

[ciaranm]

Putting something the the FAQ would not save a few people some pain. I assume you will no longer be using any of the standard Unix utilities either, since they also don't document that multiple writes to the same file at the same time aren't supported.