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

[Laszlo Papp]

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?