linux-kernel - Re: [PATCH 0/2] kernel/sys.c: for setfsgid(), return the current gid when error occurs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5201B00A.4090609@asianux.com>
Date:	Wed, 07 Aug 2013 10:25:14 +0800
From:	Chen Gang <gang.chen@...anux.com>
To:	Kees Cook <keescook@...omium.org>
CC:	Al Viro <viro@...iv.linux.org.uk>, Oleg Nesterov <oleg@...hat.com>,
	Robin Holt <holt@....com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/2] kernel/sys.c: for setfsgid(), return the current
 gid when error occurs

On 08/07/2013 02:36 AM, Kees Cook wrote:
> On Tue, Aug 6, 2013 at 1:00 AM, Chen Gang <gang.chen@...anux.com> wrote:
>> They are 2 related patches for setfsgid().
>>
>> Patch 1 for bug fix: return the current gid when error occurs.
>> Patch 2 for cleaning code: remove useless variable 'old_fsgid'.
>>
>> Signed-off-by: Chen Gang <gang.chen@...anux.com>
>> --
>>  kernel/sys.c |   15 +++++----------
>>  1 files changed, 5 insertions(+), 10 deletions(-)
> 
> Making a change like this might have dramatic effects. So, a few
> questions, to help better understand:
> 
> How long as the behavior been this way on Linux?
> What is the origin of the documentation that states it differently?
> Do existing userspace tools already depend on the current behavior?
> What specific problem will be solved by changing this?
> 

Firstly, your questions are necessary and valuable to get reply.

But sorry, I only find it by reading code, and not quite familiar with
the details (e.g. how to use it, and its history ...).

I only know the original implementation has a kernel API related issue
(at least now, it is), and try to send a possible fixing patch to
mailing list for getting more discussion and better fixing.

So, welcome any members to help reply your valuable questions (and I
should also try to answer them, but at least, I really needs time to
familiar about it).


> Thanks,
> 
> -Kees
> 

Thanks.
-- 
Chen Gang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/