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>
>
next prev parent 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.