[OE-core] busybox: passwd: applet not found

[Bernhard Reutner-Fischer]

[Cc'ing Chen who invented it for the most part]

On 20 May 2015 at 17:02, Laszlo Papp <lpapp at kde.org> wrote:
> On Wed, May 20, 2015 at 3:58 PM, Laszlo Papp <lpapp at kde.org> wrote:
>> On Wed, May 20, 2015 at 3:54 PM, Burton, Ross <ross.burton at intel.com> wrote:
>>>
>>> On 20 May 2015 at 15:50, Laszlo Papp <lpapp at kde.org> wrote:
>>>>
>>>> Currently, I do not see any simple way without #ifdef jungle in the
>>>> code around to it. It is not nice.
>>>
>>>
>>> Looking at the busybox recipe reveals this:
>>>
>>> # Whether to split the suid apps into a seperate binary
>>> BUSYBOX_SPLIT_SUID ?= "1"
>>>
>>> Just remember that the suid apps were being split out for good security
>>> reasons.  There's no need for sed to have suid rights!

The suid rights are dropped before sed_main is entered, so the potential window
is very, very small and the affected code is pretty well understood. But we had
that argument numerous times and certain users don't follow it.

>>
>> I will not argue about security measure improvements as I agree about
>> them with you. However, I will debate the way this security measure is
>> implemented. It is distraction from the desktop world where you can
>> also use busybox and many use. Now, all of a sudden, we have to handle
>> them differently in code and scripts.
>>
>> I think a less intrusive approach to implement this could have been
>> (and probably still not late) is to fix the rights underneath and not

Can you elaborate what you imagine above?

>> by such wrappers. Such wrappers will introduce this disruption which
>> is not strictly needed. Well, you could say that if desktop
>> distributions also implement it like this, then there is no
>> disruption, but I think that is never going to happen if busybox
>> itself does not enforce it.
>>
>> I think this is not a good implementation for security to remain
>> consistent with the rest of the world. Could it be please reconsidered
>> towards another solutions?
>>
>> It is also good if one call tell me how to solve this differentiation
>> between desktop and Yocto without further code.
>
> On a second thought: is even worse now than that, our code has to
> handle _three_ different scenarios:
>
> 1) Desktop.
> 2) Embedded without Yocto or embedded with old Yocto.
> 3) Embedded with new Yocto.
>
> I do not get excited about this.

Just don't set the SPLIT thing and all is well again.

Or set CONFIG_FEATURE_INDIVIDUAL so you get a shared libbusybox with
a gazillion small binaries linked to that. Not a fancy thing to do, granted.