ownership & mmaped files - I have to be missing something...

[Mike Meyer <mw...@mired.org>]

I'm working on a module that needs a couple of bits of shared memory,
some of it mmapped in. Since this is dealing with financial data,
things are run in as secure a mode as possible by default. And we want
things properly cleaned up as well.

So httpd starts as root so we can open port 80, then changes to an
unprivileged ID. If I set up the file map in the post-config-hook, it
winds up getting owned by root. In the child_init, the files isn't
mapped, so I attach it. Except I can't, because it's owned by root and
I'm no longer running as root.

Similar problems show up when I try and destroy the shared file when
I'm done with it. The cleanup run as the unprivileged ID, so can't
create the shm segments, files, etc. created by root in the init.

Is there a hook that runs after config in the parent, but as the
unprivileged id that I should be using? I couldn't find one (either in
the sources or on the web), so gave up and just set the euid before I
create those things. This seems dangerous - what if other threads are
running when I do this? 

Why does it seem that this problem isn't mentioned on the web at all?
Or is that just my search skills not being subpar? Or do people just
run everything as root for this?

Help?

	Thanks,
	<mike
-- 
Mike Meyer <mw...@mired.org>		http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

Re: ownership & mmaped files - I have to be missing something...

[Ben Noordhuis <in...@bnoordhuis.nl>]

On Thu, Nov 11, 2010 at 08:28, Mike Meyer
<mw...@mired.org> wrote:
> Is there a hook that runs after config in the parent, but as the
> unprivileged id that I should be using? I couldn't find one (either in

There isn't one, setuid() is called right before the child_init hook.

Having said that, can't you open() the file in the parent and have the
children mmap() the fd into memory? Just make sure it isn't marked as
FD_CLOEXEC.