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 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).