linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Steve Dickson <SteveD@redhat.com>
To: "Kornievskaia, Olga" <Olga.Kornievskaia@netapp.com>,
	Jeff Layton <jlayton@poochiereds.net>
Cc: Olga Kornievskaia <aglo@umich.edu>,
	linux-nfs <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH v4 2/3] gssd: using syscalls directly to change thread's identity
Date: Wed, 27 Apr 2016 11:19:21 -0400	[thread overview]
Message-ID: <5720D879.3000305@RedHat.com> (raw)
In-Reply-To: <1F119572-BB46-4F78-88B6-E6ACD01ADA93@netapp.com>



On 04/27/2016 11:01 AM, Kornievskaia, Olga wrote:
> 
>> On Apr 27, 2016, at 10:13 AM, Jeff Layton <jlayton@poochiereds.net> wrote:
>>
>> On Wed, 2016-04-27 at 10:09 -0400, Olga Kornievskaia wrote:
>>> On Tue, Apr 26, 2016 at 12:51 PM, Jeff Layton <jlayton@poochiereds.ne
>>> t> wrote:
>>>> On Tue, 2016-04-26 at 09:34 -0400, Olga Kornievskaia wrote:
>>>>> For the threaded version we have to set uid,gid per thread
>>>>> instead
>>>>> of per process. glibc setresuid() when called from a thread,
>>>>> it'll
>>>>> send a signal to all other threads to synchronize the uid in all
>>>>> other threads. To bypass this, we have to call syscall()
>>>>> directly.
>>>>>
>>>>> Signed-off-by: Olga Kornievskaia <kolga@netapp.com>
>>>>> Reviewed-by: Steve Dickson <steved@redhat.com>
>>>>> ---
>>>>>  utils/gssd/gssd_proc.c | 12 +++++++++---
>>>>>  1 file changed, 9 insertions(+), 3 deletions(-)
>>>>>
>>>>> diff --git a/utils/gssd/gssd_proc.c b/utils/gssd/gssd_proc.c
>>>>> index e2e95dc..39c4b17 100644
>>>>> --- a/utils/gssd/gssd_proc.c
>>>>> +++ b/utils/gssd/gssd_proc.c
>>>>> @@ -69,6 +69,7 @@
>>>>>  #include
>>>>>  #include
>>>>>  #include
>>>>> +#include
>>>>>
>>>>>  #include "gssd.h"
>>>>>  #include "err_util.h"
>>>>> @@ -436,7 +437,7 @@ change_identity(uid_t uid)
>>>>>       struct passwd   *pw;
>>>>>
>>>>>       /* drop list of supplimentary groups first */
>>>>> -     if (setgroups(0, NULL) != 0) {
>>>>> +     if (syscall(SYS_setgroups, 0, 0) != 0) {
>>>>>               printerr(0, "WARNING: unable to drop supplimentary
>>>>> groups!");
>>>>>               return errno;
>>>>>       }
>>>>> @@ -457,7 +458,12 @@ change_identity(uid_t uid)
>>>>>        * Switch the GIDs. Note that we leave the saved-set-gid
>>>>> alone in an
>>>>>        * attempt to prevent attacks via ptrace()
>>>>>        */
>>>>> -     if (setresgid(pw->pw_gid, pw->pw_gid, -1) != 0) {
>>>>> +     /* For the threaded version we have to set uid,gid per
>>>>> thread instead
>>>>> +      * of per process. glibc setresuid() when called from a
>>>>> thread, it'll
>>>>> +      * send a signal to all other threads to synchronize the
>>>>> uid in all
>>>>> +      * other threads. To bypass this, we have to call syscall()
>>>>> directly.
>>>>> +      */
>>>>> +     if (syscall(SYS_setresgid, pw->pw_gid, -1, -1) != 0) {
>>>>>               printerr(0, "WARNING: failed to set gid to %u!\n",
>>>>> pw->pw_gid);
>>>>>               return errno;
>>>>>       }
>>>>> @@ -466,7 +472,7 @@ change_identity(uid_t uid)
>>>>>        * Switch UIDs, but leave saved-set-uid alone to prevent
>>>>> ptrace() by
>>>>>        * other processes running with this uid.
>>>>>        */
>>>>> -     if (setresuid(uid, uid, -1) != 0) {
>>>>> +     if (syscall(SYS_setresuid, uid, -1, -1) != 0) {
>>>>>               printerr(0, "WARNING: Failed to setuid for user
>>>>> with uid %u\n",
>>>>>                               uid);
>>>>>               return errno;
>>>>
>>>> Note that the old code set both real and effective uid/gid. Here
>>>> you're
>>>> changing it to just set the real uid. Is that change deliberate? I
>>>> think you probably want to set the euid/egid as well.
>>>
>>> It was a typo (cthon tests ran fine though which is confusing since
>>> kerberos code does geteuid()). Now I'm thinking that given that we
>>> don't touch saved uid, perhaps the code should call SYS_setreuid
>>> instead of SYS_setresuid?
>>>
>>
>> Yes, good point. Either that or just set all 3 to "uid", I'd think.
> 
> There is a comment above saying leaving save-set-uid alone prevents ptrace from tracing us? 
> Do we still care about this? ptrace wiki says that a kernel can be preconfigured to prevent 
> ptrace from attaching to anything other than the traced process’ parent (that should address the comment).
I would guess not... 

steved.

> 
>>
>> -- 
>> Jeff Layton <jlayton@poochiereds.net>
> 

  reply	other threads:[~2016-04-27 15:19 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-26 13:34 [RFC PATCH v4 0/3] adding pthread support to gssd Olga Kornievskaia
2016-04-26 13:34 ` [PATCH v4 1/3] gssd: use pthreads to handle upcalls Olga Kornievskaia
2016-04-26 13:34 ` [PATCH v4 2/3] gssd: using syscalls directly to change thread's identity Olga Kornievskaia
2016-04-26 16:51   ` Jeff Layton
2016-04-27 14:09     ` Olga Kornievskaia
2016-04-27 14:13       ` Jeff Layton
2016-04-27 15:01         ` Kornievskaia, Olga
2016-04-27 15:19           ` Steve Dickson [this message]
2016-04-26 13:34 ` [PATCH v4 3/3] gssd: always call gss_krb5_ccache_name Olga Kornievskaia

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5720D879.3000305@RedHat.com \
    --to=steved@redhat.com \
    --cc=Olga.Kornievskaia@netapp.com \
    --cc=aglo@umich.edu \
    --cc=jlayton@poochiereds.net \
    --cc=linux-nfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).