Running install target with root privilages breaks subsequent invocations #1302
Comments
|
If you have a ninja target that builds anything, "sudo ninja ..." will build those intermediate outputs as root, which is also undesirable (the files will have the wrong owner and running the compiler as root). I think better would be if the install commands themselves used sudo. That is, the build file would be configured such that |
|
Putting it into the install rules is nasty: not all installs should happen as root and not all machines use sudo. |
|
Right, I meant it's up to the generator.
|
|
So the CMake dev thinks this should be solved by ninja, and you think it should be solved by CMake. Understandable, and I'm not knowledgable enough to give an opinion, but unlikely to resolve the issue. |
|
Can you link to the relevant cmake thread? |
|
It's linked to in the description: https://gitlab.kitware.com/cmake/cmake/issues/17073. |
see ninja-build#1302 as a normal workflow you do things like "ninja all && sudo ninja install" for the case that the install target executes a build target then ninja_log will be writte ntwo which will result in its permissions to be root / root, which is a problem since you cannot execute the workflow from above again.
see ninja-build#1302 as a normal workflow you do things like "ninja all && sudo ninja install" for the case that the install target executes a build target then ninja_log will be writte ntwo which will result in its permissions to be root / root, which is a problem since you cannot execute the workflow from above again.
see ninja-build#1302 as a normal workflow you do things like "ninja all && sudo ninja install" for the case that the install target executes a build target then ninja_log will be writte ntwo which will result in its permissions to be root / root, which is a problem since you cannot execute the workflow from above again.
|
Hello, How about checking if there is already a log file, if there is, ensure the permissions stay the same, if not, just rename it (and take the uid and gid of the running user)? I created PR #1362 to see how it looks in code. |
see ninja-build#1302 as a normal workflow you do things like "ninja all && sudo ninja install" for the case that the install target executes a build target then ninja_log will be writte ntwo which will result in its permissions to be root / root, which is a problem since you cannot execute the workflow from above again.
see ninja-build#1302 as a normal workflow you do things like "ninja all && sudo ninja install" for the case that the install target executes a build target then ninja_log will be writte ntwo which will result in its permissions to be root / root, which is a problem since you cannot execute the workflow from above again.
|
I faced the same issue while building the sources. |
see ninja-build#1302 as a normal workflow you do things like "ninja all && sudo ninja install" for the case that the install target executes a build target then ninja_log will be writte ntwo which will result in its permissions to be root / root, which is a problem since you cannot execute the workflow from above again.
see ninja-build#1302 as a normal workflow you do things like "ninja all && sudo ninja install" for the case that the install target executes a build target then ninja_log will be writte ntwo which will result in its permissions to be root / root, which is a problem since you cannot execute the workflow from above again.
see ninja-build#1302 as a normal workflow you do things like "ninja all && sudo ninja install" for the case that the install target executes a build target then ninja_log will be writte ntwo which will result in its permissions to be root / root, which is a problem since you cannot execute the workflow from above again.
see ninja-build#1302 as a normal workflow you do things like "ninja all && sudo ninja install" for the case that the install target executes a build target then ninja_log will be writte ntwo which will result in its permissions to be root / root, which is a problem since you cannot execute the workflow from above again.
see ninja-build#1302 as a normal workflow you do things like "ninja all && sudo ninja install" for the case that the install target executes a build target then ninja_log will be writte ntwo which will result in its permissions to be root / root, which is a problem since you cannot execute the workflow from above again.
see ninja-build#1302 as a normal workflow you do things like "ninja all && sudo ninja install" for the case that the install target executes a build target then ninja_log will be writte ntwo which will result in its permissions to be root / root, which is a problem since you cannot execute the workflow from above again.
see ninja-build#1302 as a normal workflow you do things like "ninja all && sudo ninja install" for the case that the install target executes a build target then ninja_log will be writte ntwo which will result in its permissions to be root / root, which is a problem since you cannot execute the workflow from above again.
see ninja-build#1302 as a normal workflow you do things like "ninja all && sudo ninja install" for the case that the install target executes a build target then ninja_log will be writte ntwo which will result in its permissions to be root / root, which is a problem since you cannot execute the workflow from above again.
see ninja-build#1302 as a normal workflow you do things like "ninja all && sudo ninja install" for the case that the install target executes a build target then ninja_log will be writte ntwo which will result in its permissions to be root / root, which is a problem since you cannot execute the workflow from above again.
see ninja-build#1302 as a normal workflow you do things like "ninja all && sudo ninja install" for the case that the install target executes a build target then ninja_log will be writte ntwo which will result in its permissions to be root / root, which is a problem since you cannot execute the workflow from above again.
|
Same problem here. Always have to do a |
see ninja-build#1302 as a normal workflow you do things like "ninja all && sudo ninja install" for the case that the install target executes a build target then ninja_log will be writte ntwo which will result in its permissions to be root / root, which is a problem since you cannot execute the workflow from above again.
see ninja-build#1302 as a normal workflow you do things like "ninja all && sudo ninja install" for the case that the install target executes a build target then ninja_log will be writte ntwo which will result in its permissions to be root / root, which is a problem since you cannot execute the workflow from above again.
see ninja-build#1302 as a normal workflow you do things like "ninja all && sudo ninja install" for the case that the install target executes a build target then ninja_log will be writte ntwo which will result in its permissions to be root / root, which is a problem since you cannot execute the workflow from above again.
|
It seems we can consider that as a major issue and the problem seems well understood. So, I am surprised it is not yet fixed after 5 years. can I help on that issue? What is the problem with the proposed workaround? (a bit hacky maybe?) |
|
Fundamentally when you run Ninja's policy is that if you need some specific behavior for some specific task it executes, it's up to you to generate a ninja file that contains the specific task you need executed. For that reason I think it does belong in the generator. (Alternatively you could run your entire build as root, which seems like a bad idea in general, but that's up to you...) |
This comment was marked as abuse.
This comment was marked as abuse.
|
For the record, the user can run It is probably a bit less hacky than playing with |
|
@jonesmz your suggestion looks like the patch submitted by @marcelhollerbach. Why it has not been accepted? |
This comment was marked as abuse.
This comment was marked as abuse.
|
This comment was marked as abuse.
This comment was marked as abuse.
|
Hi all involved, it has now been another year but unfortunately I can still produce this another year on. In my build I have gone to some extend using the chown-hack but that is not as reliable as I have hoped. Could I implore you to find a good solution that would work in conjunction with cmake? It surely helps nobody if
Thank you. |
A "common pattern" for a library is to run
makeand thensudo make install. This works nicely with CMake. However, when using Ninja as the underlying build system,sudo ninja installchanges the owner of.ninja_logto root. Subsequent invocations ofninjathan fail withJust deleting the file afterwards seems fine, but this is not the way to go, right? When I raised this issue on CMake, one suggestion was for Ninja to try and write the log file with the original owner if it is run as root. What do you think?
The text was updated successfully, but these errors were encountered: