[PATCH]: core files with make testenv

[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)
> -- 
> 1.7.9.5

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?

Thanks,

Andrew Bartlett
-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org