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

[Laszlo Papp]

On Wed, May 20, 2015 at 4:48 PM, Bernhard Reutner-Fischer
<rep.dot.nop at gmail.com> wrote:
> 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.

Well, I understand and appreciate that opinions vary, but if busybox
had shipped 3 binaries at the end of the build processes, then their
naming would be "standard" led by busybox upstream. Currently, there
is no way to standardize it if Yocto thinks it should be called
busybox.suid and e.g. (imaginary example) buildroot thinks it should
be called suid.busybox. This would be less than ideal if my software
has to work with both.

Yes, Denys would need to be convinced for this, but for the time
being, I do not have enough time to get it through.

Anyway, thank you for your replies. I deem them helpful and prompt.