Ticket #545 (closed defect: wontfix)

Opened 10 years ago

Last modified 10 years ago

Support for parallel paludis operations

Reported by: chaoflow Owned by: ciaranm
Priority: Sometime Milestone:
Component: clients/paludis Version: 0.26.0_alpha14
Keywords: Cc:
Blocked By: Blocking:
Distribution:

Description

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

Change History

comment:1 follow-up: ↓ 2 Changed 10 years ago by ciaranm

  • Status changed from new to closed
  • Resolution set to wontfix

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.

comment:2 in reply to: ↑ 1 ; follow-up: ↓ 3 Changed 10 years ago by 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?

comment:3 in reply to: ↑ 2 ; follow-up: ↓ 4 Changed 10 years ago by 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.

comment:4 in reply to: ↑ 3 ; follow-up: ↓ 5 Changed 10 years ago by 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?

comment:5 in reply to: ↑ 4 Changed 10 years ago by 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.

comment:6 follow-up: ↓ 7 Changed 10 years ago by chaoflow

  • Status changed from closed to reopened
  • Version changed from 0.26.0_alpha13 to 0.26.0_alpha14
  • Resolution wontfix deleted

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.

comment:7 in reply to: ↑ 6 Changed 10 years ago by ciaranm

  • Status changed from reopened to closed
  • Resolution set to wontfix

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.

comment:8 Changed 10 years ago by 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!

comment:9 Changed 10 years ago by 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.

Note: See TracTickets for help on using tickets.