From: Jeff Layton <jlayton@poochiereds.net>
To: Olga Kornievskaia <aglo@umich.edu>
Cc: Steve Dickson <SteveD@redhat.com>,
Jeff Layton <layton@primarydata.com>,
Olga Kornievskaia <kolga@netapp.com>,
linux-nfs <linux-nfs@vger.kernel.org>
Subject: Re: [RFC PATCH v2 2/3] gssd: using syscalls directly to change thread's identity
Date: Mon, 25 Apr 2016 16:37:29 -0400 [thread overview]
Message-ID: <1461616649.4288.35.camel@poochiereds.net> (raw)
In-Reply-To: <CAN-5tyEbOQoCEB0EDCXAi2BTdH-VCwfyipAqtAb61P8WxRJ9NA@mail.gmail.com>
On Mon, 2016-04-25 at 12:56 -0400, Olga Kornievskaia wrote:
> On Sat, Apr 23, 2016 at 11:24 PM, Jeff Layton wrote:
> >
> > On Sat, 2016-04-23 at 17:14 -0400, Steve Dickson wrote:
> > >
> > >
> > > On 04/22/2016 04:41 PM, Olga Kornievskaia wrote:
> > > >
> > > >
> > > > On Fri, Apr 22, 2016 at 2:38 PM, Steve Dickson
> > > > wrote:
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On 04/20/2016 05:12 PM, 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 | 10 ++++++++--
> > > > > > 1 file changed, 8 insertions(+), 2 deletions(-)
> > > > > >
> > > > > > diff --git a/utils/gssd/gssd_proc.c b/utils/gssd/gssd_proc.c
> > > > > > index 581a125..5d9a6db 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"
> > > > > > @@ -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) != 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) != 0) {
> > > > > > printerr(0, "WARNING: Failed to setuid for user
> > > > > > with uid %u\n",
> > > > > > uid);
> > > > > > return errno;
> > > > > >
> > > > > We also have to do the same thing to the setgroups() call at the
> > > > > top of change_identity(). So add the following diff to this
> > > > > patch and we are good to go...
> > > > >
> > > > > diff --git a/utils/gssd/gssd_proc.c b/utils/gssd/gssd_proc.c
> > > > > index e651d71..2f9f8ab 100644
> > > > > --- a/utils/gssd/gssd_proc.c
> > > > > +++ b/utils/gssd/gssd_proc.c
> > > > > @@ -437,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) {
> > > > > printerr(0, "WARNING: unable to drop
> > > > > supplimentary groups!");
> > > > > return errno;
> > > > > }
> > > > >
> > > > Do you know why we do this before getting the passwd entry?
> > > It came in with commit 6b53fc9c which changed the way gssd
> > > changed the uid/gid from Jeff Layton...
> > >
> > > Jeff, what was the thought behind dropping supplementary groups?
> > > I believe it was some type of security thing.
> > >
> > We do that so that the child doesn't run with supplementary groups from
> > the main process.
> >
> > As to why we do that before getting the passwd entry instead of after?
> > No real reason for the order that I can recall. If you need to do it
> > after the pw entry, I don't think it'll matter.
> >
> > That said, since this has to run as root anyway, I guess you could drop
> > the supplementary groups in the main process. Then all of the children
> > should get a zeroed out grouplist, and it's one less syscall...
> Thank Jeff, I thought that since we are setting the effective uid/gid
> of the process (or with the patches, thread), then the child process
> (thread) would have the supplementary groups associated with the given
> uid.
>
No. Calling seteuid should have no effect on the supplementary groups
list, AFAIK. Oh, and yeah...the manpage says:
setgroups() sets the supplementary group IDs for the calling process.
Appropriate privileges (Linux: the CAP_SETGID capability) are required.
So you do need to clean out the groupslist and gids first and only
afterward set the uids.
> > >
> > > >
> > > > Doing as you suggest causes problems as in it it fails to drop the
> > > > supplementary groups.
> > > hmm... what are you seeing that I'm not?
> It was my bad. I decided to change the order of when the call is done
> (ie., doing it after the setting the uid and gid) and that causes an
> error. Perhaps it's becuase once the uid is changed to some user's
> uid, then that uid no longer has the ability to drop the supplementary
> groups.
>
> Going to send a new version of patches...
>
> >
> > >
> > >
> > > steved.
> > >
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe linux-nfs"
> > > in
> > > the body of a message to majordomo@vger.kernel.org
> > > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > --
> > Jeff Layton <jlayton@poochiereds.net>
> >
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Jeff Layton <jlayton@poochiereds.net>
next prev parent reply other threads:[~2016-04-25 20:37 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-20 21:11 [RFC PATCH v2 0/3] adding pthread support to gssd Olga Kornievskaia
2016-04-20 21:11 ` [RFC PATCH v2 1/3] gssd: use pthreads to handle upcalls Olga Kornievskaia
2016-04-22 18:36 ` Steve Dickson
2016-04-20 21:12 ` [RFC PATCH v2 2/3] gssd: using syscalls directly to change thread's identity Olga Kornievskaia
2016-04-22 18:38 ` Steve Dickson
2016-04-22 20:41 ` Olga Kornievskaia
2016-04-23 21:14 ` Steve Dickson
2016-04-24 3:24 ` Jeff Layton
2016-04-25 16:56 ` Olga Kornievskaia
2016-04-25 20:37 ` Jeff Layton [this message]
2016-04-20 21:12 ` [RFC PATCH v2 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=1461616649.4288.35.camel@poochiereds.net \
--to=jlayton@poochiereds.net \
--cc=SteveD@redhat.com \
--cc=aglo@umich.edu \
--cc=kolga@netapp.com \
--cc=layton@primarydata.com \
--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.