Re: [PATCH 1/2] kernel/sys.c: return the current gid when error occurs

[Chen Gang]

On 08/08/2013 09:52 PM, Michael Kerrisk (man-pages) wrote:
> On 08/08/13 03:48, Chen Gang wrote:
>> On 08/08/2013 09:35 AM, Andy Lutomirski wrote:
>>> On Wed, Aug 7, 2013 at 6:30 PM, Chen Gang <gang.chen@xxxxxxxxxxx> wrote:
>>>> On 08/08/2013 12:58 AM, Andy Lutomirski wrote:
>>>>> On Wed, Aug 7, 2013 at 9:21 AM, Oleg Nesterov <oleg@xxxxxxxxxx> wrote:
>>>>>> On 08/06, Andy Lutomirski wrote:
>>>>>>>
>>>>>>> I assume that what the man page means is that the return value is
>>>>>>> whatever fsgid was prior to the call.  On error, fsgid isn't changed, so
>>>>>>> the return value is still "current".
>>>>>>
>>>>>> Probably... Still
>>>>>>
>>>>>>         On success, the previous value of fsuid is returned.
>>>>>>         On error, the current value of fsuid is returned.
>>>>>>
>>>>>> looks confusing. sys_setfsuid() always returns the old value.
>>>>>>
>>>>>>> (FWIW, this behavior is awful and is probably the cause of a security
>>>>>>> bug or three, since success and failure are indistinguishable.
>>>>>>
>>>>>> At least this all looks strange.
>>>>>>
>>>>>> I dunno if we can change this old behaviour. I won't be surprized
>>>>>> if someone already uses setfsuid(-1) as getfsuid().
>>>>>
>>>>
>>>> Oh, really it is.
>>>>
>>>> Hmm... as a pair function, we need add getfsuid() too, if we do not add
>>>> it, it will make negative effect with setfsuid().
>>>>
>>>> Since it is a system call, we have to keep compitable.
>>>>
>>>> So in my opinion, better add getfsuid2()/setfsuid2() instead of current
>>>> setfsuid()
>>>
>>> How about getfsuid() and setfsuid2()?
>>>
>>
>> Hmm... I have 2 reasons, please check.
>>
>> 1st reason: I checked history (just like Kees Cook suggested),
>> getfsuid() is mentioned before (you can google to find it), so need use
>> getfsuid2() to bypass the history complex.
>>
>> And 2nd reason: getfsuid() seems more like the pair of setfsuid(), not
>> for setfsuid2().
> 
> Time to apply the brakes... *Why* add new system calls here? I don't 
> think there is any good reason. Yes, the existing APIs are rubbish,
> but, as far as I can tell, they are also obsolete and unneeded.
> The fsuid/fsgid mechanism was a bizarre Linuxism whose only purpose
> was (as far as I know), to allow for the fact that Linux long ago
> applied nonstandard rules when determining when one process could 
> send signals to another. Quoting some book on the subject:
> 
>     Why does Linux provide the file-system IDs and in what 
>     circumstances would we want the effective and file-system 
>     IDs to differ? The reasons are primarily historical.
>     The file-system IDs first appeared in Linux 1.2. In 
>     that kernel version, one process could send a signal to 
>     another if the effective user ID of the sender matched
>     the real or effective user ID of the target process. 
>     This affected certain programs such as the Linux NFS 
>     (Network File System) server program, which needed to be
>     able to access files as though it had the effective IDs 
>     of the corresponding client process. However, if the NFS 
>     server changed its effective user ID, it would be 
>     vulnerable to signals from unprivileged user processes. 
>     To prevent this possibility, the separate file-system user
>     and group IDs were devised. By leaving its effective IDs
>     unchanged, but changing its file-system IDs, the NFS 
>     server could masquerade as another user for the purpose of 
>     accessing files without being vulnerable to signals from
>     user processes.
> 
>     From kernel 2.0 onward, Linux adopted the SUSv3-mandated 
>     rules regarding permission for sending signals, and these 
>     rules don't involve the effective user ID of the target
>     process. Thus, the file-system ID feature is no longer 
>     strictly necessary (a process can nowadays achieve the 
>     desired results by making judicious use of the system
>     calls described later in this chapter to change
>     the value of the effective user ID to and from an
>     unprivileged value, as required), but it remains for
>     compatibility with existing software.
> 
> So, I don't think anything needs fixing: there should be no 
> new users of these system calls anyway.
> 

OK, thank you for your details, at least for me, what you says above
sounds reasonable.

> Cheers,
> 
> Michael
> 
> 

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