Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (nike.apache.org: domain of ivan@visualsvn.com designates
 209.85.212.177 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAKUrXK6zM_LCWC5-+UQZ-C7JNWXM8ym+rGRLVFQwgRY4mT71=Q@mail.gmail.com>
References: 
 <CAKUrXK6zM_LCWC5-+UQZ-C7JNWXM8ym+rGRLVFQwgRY4mT71=Q@mail.gmail.com>
From: Ivan Zhakov <ivan@visualsvn.com>
Date: Mon, 14 Oct 2013 12:34:47 +0400
Message-ID: 
 <CABw-3Yca2ebVzmQ7O8quw0E8YOMyQZwYtBNr9K-ho0wRbhk_ig@mail.gmail.com>
Subject: Re: [PATCH] "Global" vs. "Local" prefix on named mutexes and named
 shm on Windows
To: Jeff Trawick <trawick@gmail.com>
Cc: APR Developer List <dev@apr.apache.org>
Content-Type: text/plain; charset=UTF-8

On 12 October 2013 18:48, Jeff Trawick <trawick@gmail.com> wrote:
> With APR on Windows, creating shared memory or a cross-process mutex with a
> "file" name parameter results in a resource being created with a "Global"
> prefix, which in turn restricts the call to Administrator (or more
> accurately, a thread with the specific privilege
> to make that call; let's just call that "Administrator" for simplicity).  (I
> think this is just for shared memory???)
>
> A typical way to encounter this is that some dude in httpd-land decides that
> mod_lua should start creating APR shared memory at startup and a filename
> should always be specified, and suddenly httpd running as you on Windows can
> no longer use mod_lua.  Any number of other httpd modules try do something
> similar (though I haven't investigated if there's a way to configure around
> it); additionally, APR's testshm won't work as a regular user.
>
> The attached patch uses "Local" as the prefix if the calling thread doesn't
> have the necessary privilege to create one under the global namespace.  But
> this function is also used for attach-type operations,
>
> Has anyone investigated this before?
>
Jeff,

It looks like very dangerous change. Local and Global namespaces are
completely separate, thus priviliged process could not access
shm/mutex created by unprivileged process. Objects in local kernel
namespace are per session, while objects in global kernel namespace
are shared across all sessions, that's why process need additional
privilege to create them.

Services are started in separate "session 0", while interactive
processes uses dedicated session for every user/rdp connection.

Your patch may also break atomic "create or open" code:
[[
rv == apr_shm_create();
if (rv == ALREADY_EXIST)
   rv = apr_shm_attach()
]]

Suppose Windows services created shm object in global namespace,
interactive process wanted to access it using code above.
apr_shm_create() detects that process is not privileged and creates
shm object in local namespace, which is wrong IMHO.

Change process privileges as side effect of apr_shm_attach() is also
nasty behavior imho.

-- 
Ivan Zhakov