mkelfimage creates read only output. This causes the build script to error with a permission denied when it tries to overwrite a payload created by mkelfimage.
Eric Biederman requested that we mod the script rather than change the output of mkelfimage upstream.
* Richard Smith smithbone@gmail.com [060710 00:41]:
mkelfimage creates read only output. This causes the build script to error with a permission denied when it tries to overwrite a payload created by mkelfimage.
Eric Biederman requested that we mod the script rather than change the output of mkelfimage upstream.
Eric,
I would say that this misses the point of write permissions. What's the reason for mkelfImage setting its results read-only in the first place? No other payloads have such a behavior. Can you please explain your decision a little bit? From the outside this definitely looks like the issue needs to be fixed in mkelfImage.
Stefan
Stefan Reinauer stepan@coresystems.de writes:
- Richard Smith smithbone@gmail.com [060710 00:41]:
mkelfimage creates read only output. This causes the build script to error with a permission denied when it tries to overwrite a payload created by mkelfimage.
Eric Biederman requested that we mod the script rather than change the output of mkelfimage upstream.
Eric,
I would say that this misses the point of write permissions. What's the reason for mkelfImage setting its results read-only in the first place? No other payloads have such a behavior. Can you please explain your decision a little bit? From the outside this definitely looks like the issue needs to be fixed in mkelfImage.
As best as I can recall of the original decision making process.
A common use of mkelfImage has been to put a bootable ELF image in /tftpboot. In that scenario someone may be downloading the image when you are updating it. Therefore to correctly update the file, you must first write to a new filename and then move it to the new filename. Which gives you atomic update permissions.
The goal was to catch issues where people did not do that.
That is exactly what was caught here.
If the problem was one where what you are updating needs to be writable I would agree that it is not a build script issue. However since you don't need write permissions and are just stomping on the file we are doing the wrong thing in the build.
Show me a case where you actually need write permissions and I will be sympathetic.
While I think it can be argued that mkelfImage is wrong I think the case is that our build process is even more incorrect.
Is there ever a case where writing to an active executable does the correct thing?
Eric
A common use of mkelfImage has been to put a bootable ELF image in /tftpboot. In that scenario someone may be downloading the image when you are updating it. Therefore to correctly update the file, you must first write to a new filename and then move it to the new filename. Which gives you atomic update permissions.
Ah... Thanks for the clarification.
The goal was to catch issues where people did not do that.
That is exactly what was caught here.
Not quite. This was just for a normal fallback build for the in-flash kernel using a payload directive in the config file.
If the problem was one where what you are updating needs to be writable I would agree that it is not a build script issue. However since you don't need write permissions and are just stomping on the file we are doing the wrong thing in the build.
Stefan. I think Eric's right and the build script needs the tweak regardless of the output of mkelfimage. If the users umask is set restrictive then the same problem would occur. I noticed in the makefile that there are a few other cp's that probably need to be cp -f as well.
Ok to commit?
* Richard Smith smithbone@gmail.com [060710 20:45]:
Stefan. I think Eric's right and the build script needs the tweak regardless of the output of mkelfimage. If the users umask is set restrictive then the same problem would occur. I noticed in the makefile that there are a few other cp's that probably need to be cp -f as well.
Ok to commit?
commited.
-
ebiederman＠lnxi.com -
Richard Smith -
Stefan Reinauer