Fwd: NOFORK and NOEXEC without PREFER_APPLETS

[Bruno Chevalier]

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.


Am I overlooking something? Because I can't see the direct link between
PREFER_APPLETS and NOEXEC/NOFORK.
If the applet isn't the first in the path, we can't do the tricks,
otherwise we can.

Kind regards,
Bruno
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/busybox/attachments/20160720/0f21656d/attachment.html>