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

[Bernhard Reutner-Fischer]

On May 20, 2015 5:36:55 PM GMT+02:00, Laszlo Papp <lpapp at kde.org> wrote:
>On Wed, May 20, 2015 at 4:25 PM, Bernhard Reutner-Fischer
><rep.dot.nop at gmail.com> wrote:
>> On 20 May 2015 at 17:20, Laszlo Papp <lpapp at kde.org> wrote:
>>> On Wed, May 20, 2015 at 4:17 PM, Bernhard Reutner-Fischer
>>> <rep.dot.nop at gmail.com> wrote:
>>>> On 20 May 2015 at 17:09, Laszlo Papp <lpapp at kde.org> wrote:
>>>>> On Wed, May 20, 2015 at 4:07 PM, Burton, Ross
><ross.burton at intel.com> wrote:
>>>>>>
>>>>>> On 20 May 2015 at 16:02, Laszlo Papp <lpapp at kde.org> wrote:
>>>>>>>
>>>>>>> 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.
>>>>>>
>>>>>>
>>>>>> Do as the documentation says in your distro and you have one
>scenario.
>>>>>
>>>>> That means compromising security. I am now looking for the ideal
>case
>>>>> in the future. What is wrong about dropping the privileges in
>busybox
>>>>> for undedicated processes without creating this separation?
>>>>>
>>>>> That would combine the convenience with security, wouldn't it?
>>>>
>>>> We already do that. Since June 2002. version 0.60.4
>>>
>>> Then I cannot understand the incompatible change. If the privilege
>is
>>> dropped early and the code is well-understood, then what exactly was
>>> being solved in here for the price of incompatibility and more
>complex
>>> environments across projects?
>>>
>>> But in any case, if BUSYBOX_SPLIT_SUID=0 helps me with being
>>> compatible while it still drops the privileges properly as intended
>by
>>> busybox upstream, I guess I can go for that. I am yet to understand
>>> the "certain users do not follow it" part. What exactly?
>>
>> Certain users don't want to risk bugs in the code before privs are
>dropped.
>> The only way to make them happy is to split the binary into two, a
>suid
>> one a a nosuid one.
>
>OK, well, in that case, the question is: why is it not led by busybox
>upstream? Currently, busybox downstream projects can call this
>anything. At least, some standard way would be nice, wouldn't it?

The logic where to split is upstream to attempt to have a stable, maintained interface at least.
I do not want 2 binaries myself. If there is an attack-vector in the part before dropping privileges then I want to have it fixed.

You can ask Denys if he wants to do the 2 binary nonsense upstream, but I will not commit such a thing, fwiw.

Cheers,