Re: [PATCH] proc: move the adding option Ngid to the end of proc/PID/status

[ebiederm@xmission.com (Eric W. Biederman)]

"Wang, Xiaoming" <xiaoming.wang@intel.com> writes:

> Dear tejun
>
>> -----Original Message-----
>> From: htejun@gmail.com [mailto:htejun@gmail.com] On Behalf Of Tejun Heo
>> Sent: Friday, April 17, 2015 11:42 AM
>> To: Wang, Xiaoming
>> Cc: akpm@linux-foundation.org; oleg@redhat.com;
>> andriy.shevchenko@linux.intel.com; linux@rasmusvillemoes.dk;
>> ebiederm@xmission.com; eparis@redhat.com; chenhanxiao@cn.fujitsu.com;
>> tglx@linutronix.de; linux-kernel@vger.kernel.org; Schallberger, Timothy M;
>> Zhang, Dongxing
>> Subject: Re: [PATCH] proc: move the adding option Ngid to the end of
>> proc/PID/status
>> 
>> On Thu, Apr 16, 2015 at 11:37 PM, Wang, Xiaoming
>> <xiaoming.wang@intel.com> wrote:
>> >> git describe --contains says 3.13 and it's about 1.5 years ago.
>> >>
>> > Yes this kernel change is 1.5 years ago.
>> > As we known not all user update the kernel so frequently.
>> > They just use the stable one.
>> > We met this issue when update to 3.13 now.
>> > A lot of application failed to run which run well previously.
>> > Do you have any idea on this issue?
>> 
>> Not really. It's a sucky situation. How many applications are we talking about? I
>> tried to find information on libsecuritysdk but couldn't find it anywhere.
>> 
> This lib libsecuritysdk is included in application.
> Taobao, weibo,  tmall, alipay, etc
> It refer to security .

*cough* snake oil *cough*  

Buggy non-robust code that is sold as providing a security function
deeply disturbs me.   In this case libsecuritysdk is clearly buggy.  The
point of labels at the beginning of lines is so that order is irrelevant.

If this had been reported by someone who cares enough to test any time
during the 6 weeks of an rc series or even shortly after a stable
release we would have take this patch immediately.   Because breaking
userspace is something we don't want to do, and it would have been clear
what the trade-offs are.

In this case Tejun is right.  We need to weigh the risk of fixing one
application against the risk of breaking others.  So far there has been
no analysis about the possibility what other software might be affected
by this change.

With respect to testing, linux is developed as a community and it is the
responsibility for everyone in the community to pitch in and do what
they can for the bits they care about.

As best as I can infer libsecuritysdk is doing it's best to ensure that
a debugger is not attached while the library is being run.  The code
appears to be binary and proprietary.  So the entire community of
developers can not go out and read the code and see what is going on.
This places a higher burden on those who develop and maintian
libsecuritysdk to test and to verify their software will work with
future versions of the linux kernel, and to more promptly bring issues
to our attention.

In this instance until due dilligence has been done to indicate that
making the change proposed will not result in another bug report in
another 1.5 years from now about a different piece of software I am
inclined to strongly suggest we do nothing.

Further is there any indication that even with this small change that
the applications that use libsecuritysdk will work on 4.1-rc1 when it
comes out in the next couple of days?  Or even that those applications
work on 4.0?

Eric