On Wed, Jan 17, 2018 at 10:41:21AM -0500, Michael Orlitzky wrote:
> If I want to create /run/foo and /run/foo/bar, both owned by the "foo"
> user, how would I do it using newpath?
> 
> 1. I could create /run/foo with owner "foo", and then create
>    /run/foo/bar with owner "foo". That can be done without modifying
>    existing permissions, but it's not safe, because you wind up working
>    as root in the directory /run/foo which is owned by the non-root
>    "foo" user. If newpath disallows that unsafe operation, this approach
>    is out.
> 
> 2. I could create /run/foo as root:root, and then create /run/foo/bar as
>    "foo". That much is safe, but then what do I do about /run/foo? It
>    already exists, so if newpath will refuse to modify existing paths,
>    then this approach is out too.
> 
> That leaves...
> 
> 3. I can create /run/foo with owner "foo", and then setuid to the foo
>    user. Now, *as the foo user* I can create /run/foo/bar, which will be
>    owned by "foo". There's no risk in doing so, because the "foo" user
>    can only trick himself. Moreover, the directory is writable only by
>    root and the OpenRC user (currently: foo) at that point, so the extra
>    safety precautions don't get in the way.

Everything I'm saying here assumes that /run/foo and /run/foo/bar do not
exist. If they do, both approaches 1 and 3 will do nothing other than
warn if the permissions or ownership has changed.

In both approaches 1 and 3, the first step will be to create the
directory /run/foo then optionally adjust permissions on it. At that
point newpath will exit.

When the second invocation of newpath starts, we know /run/foo/bar
does not exist, and creating /run/foo/bar will fail if /run/foo doesn't
exist.

Since that's true, I don't see what the difference is
between approaches 1 and 3 or what makes approach 1 so unsafe. Call me
dense if you must, lol, I'm just not getting it. At this point we know
that /run/foo is owned by foo, and I've never heard that root working in
a directory it doesn't own isn't safe.

William

Attachment: signature.asc
Description: Digital signature

Reply via email to