On 10/31/2014 11:15 PM, Peter A. Bigot wrote:
On 10/13/2014 05:35 PM, Peter Seebach wrote:
On Mon, 13 Oct 2014 17:29:26 -0500
"Peter A. Bigot" wrote:
Basically, even if "root" is a special case, taking this path means
making assumptions about what the application is doing based on what
system
On 10/13/2014 05:35 PM, Peter Seebach wrote:
On Mon, 13 Oct 2014 17:29:26 -0500
"Peter A. Bigot" wrote:
Basically, even if "root" is a special case, taking this path means
making assumptions about what the application is doing based on what
system/libc functions it invokes. Too often when som
On Mon, 13 Oct 2014 17:29:26 -0500
"Peter A. Bigot" wrote:
> Basically, even if "root" is a special case, taking this path means
> making assumptions about what the application is doing based on what
> system/libc functions it invokes. Too often when somebody assumes a
> general tool will onl
On 10/13/2014 04:28 PM, Peter Seebach wrote:
On Sun, 12 Oct 2014 18:49:52 -0500
"Peter A. Bigot" wrote:
I believe OE should add --without-passwd-fallback to the pseudo 1.6.2
configuration flags early in the 1.8 development cycle, to ensure there
are no host contamination issues. I can think o
On Sun, 12 Oct 2014 18:49:52 -0500
"Peter A. Bigot" wrote:
> I believe OE should add --without-passwd-fallback to the pseudo 1.6.2
> configuration flags early in the 1.8 development cycle, to ensure there
> are no host contamination issues. I can think of no reason why the
> build host passwd an
While determining that an anomaly was self-induced, I found some issues
with pseudo that, with low probability, could result in mis-use of the
build host /etc/passwd and /etc/group to resolve target uid/gid/names.
The red herring I was fishing was that pseudo, in its default
configuration, will fa
