[PATCH]: core files with make testenv
gb at sernet.de
Mon Jun 3 06:47:57 MDT 2013
I did not understand the reasons for doing chown here, so I tried to make it
Maybe removing it alltogether is the right thing todo.
Am Samstag, 25. Mai 2013, 08:28:00 schrieb Andrew Bartlett:
> On Mon, 2013-04-22 at 14:18 +0200, Gregor Beck wrote:
> > >From 031160dc983e92925b344961eccd596672727859 Mon Sep 17 00:00:00
> > 2001
> > From: Gregor Beck <gbeck at sernet.de>
> > Date: Mon, 22 Apr 2013 13:33:00 +0200
> > Subject: [PATCH 2/2] s3: let the effective user of the parent smbd own
> > the
> > core dump dir.
> > This prevents the chown to fail in testenv and seems to do the right
> > thing in
> > normal operation.
> > ---
> > source3/lib/dumpcore.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> > diff --git a/source3/lib/dumpcore.c b/source3/lib/dumpcore.c
> > index 90acc16..d41f258 100644
> > --- a/source3/lib/dumpcore.c
> > +++ b/source3/lib/dumpcore.c
> > @@ -66,7 +66,7 @@ static char *get_default_corepath(const char
> > *logbase, const char *progname)
> > if (mkdir(tmp_corepath, 0700) == -1 && errno != EEXIST)
> > goto err_out;
> > - if (chown(tmp_corepath, getuid(), getgid()) == -1)
> > + if (chown(tmp_corepath, geteuid(), getegid()) == -1)
> > goto err_out;
> > if (chmod(tmp_corepath, 0700) == -1)
> I'm sorry, but this looks wrong to me. If the mkdir didn't create the
> directory with the correct owner, then how is a chown going to help?
> The mkdir would have created the file with the current effective
> uid/gid, so why change it again?
> I know uid_wrappper is part of the game here, making these functions
> return results that don't 'work', but if the original intent was to
> ensure the files were changed from EUID (perhaps the user) to UID
> (perhaps root?), then this seems quite wrong.
> Perhaps it should just check the ownership against sec_initial_uid if
> that isn't going to cause dependency pain?
> Andrew Bartlett
More information about the samba-technical