Hi again, I have tested if the disentangled features showed the required behavior. The NOFORK trick works as needed now, but the NOEXEC trick does not behave as needed in the proposed scenario.
I have attached a patch that shows the required behavior by introducing a new feature. Is there a possibility of getting this feature upstream? If not, what are the requirements that need to be fulfilled before a new feature can be added to busybox? Also, are there any changes that can make this code better? Kind regards, Bruno Chevalier On 24 July 2016 at 19:33, Bruno Chevalier <[email protected]> wrote: > Thanks Denys, > I will redo the tests that I did, because as far as I know, that was the > behaviour that I observed. > I could be wrong though, so I will redo them. > > I will also do the tests with the latest git repo and let you know the > results. > > On 22 July 2016 at 18:50, Denys Vlasenko <[email protected]> wrote: > >> On Wed, Jul 20, 2016 at 3:01 PM, Bruno Chevalier >> <[email protected]> wrote: >> > Hi, >> > >> > I am wondering why FEATURE_PREFER_APPLETS needs to be enabled for the >> > FEATURE_SH_STANDALONE (to do the NOEXEC trick) and FEATURE_SH_NOFORK >> (to do >> > the NOFORK trick). >> > >> > If the applet tables would always contain the NOFORK/NOEXEC bits, the >> > FEATURE_PREFER_APPLETS wouldn't be mandatory anymore. >> > You can look in the path and if the executable that gets found for a >> > specific command is busybox, then we can do the NOEXEC or NOFORK trick. >> > Otherwise, we just execute the program that was found using PATH in the >> > normal way. >> > >> > A use case for this is the following: >> > Let's say we have 2 buildroot configurations. >> > We als have one common busybox configuration that contains the hexdump >> > applet and that gets used for both buildroot configurations. >> > >> > 1 buildroot configuration contains a version of hexdump that overwrites >> the >> > busybox implementation, the other doesn't. >> > >> > We notice that hexdump is a NOEXEC app and we want to take advantage of >> > this. >> > >> > In the current implementation of busybox we have two scenarios: >> > 1. We enable FEATURE_PREFER_APPLETS and FEATURE_SH_STANDALONE. This >> way, the >> > hexdump that gets executed is always the busybox implementation and it >> makes >> > use of the NOEXEC trick. >> > We can make use of the NOEXEC trick, but the buildroot configuration >> that >> > included hexdump does not execute its own hexdump by default unless you >> > specify the complete path. >> > >> > 2. We don't enable FEATURE_PREFER_APPLETS. Now we execute the hexdump >> from >> > buildroot in the buildroot config that enabled it and we execute the >> hexdump >> > from busybox in the buildroot config that didn't include hexdump. >> > However, the busybox version does not make use of the NOEXEC trick >> because >> > that feature cannot be enabled without FEATURE_PREFER_APPLETS. >> > >> > >> > Now we would like to be able to do scenario 2, but when the busybox >> version >> > gets executed, we still want the NOEXEC trick to be used. >> >> Enabling FEATURE_SH_STANDALONE does not give you case 2: hexdump >> from buildroot won't be executed, internal applet takes precedence. IOW: >> " Now we execute the hexdump from >> > buildroot in the buildroot config that enabled it and we execute the >> hexdump >> > from busybox in the buildroot config that didn't include hexdump." >> will not be true, AFAICS. >> >> I committed a fix which makes it possible to choose FEATURE_SH_STANDALONE >> and/or NOFORK without FEATURE_PREFER_APPLETS. Please try current git. >> > >
Add-FEATURE_SH_PATH_BEFORE_NOEXEC.patch
Description: Binary data
_______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
