From: William Hubbs <williamh@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Cc: mjo@gentoo.org
Subject: Re: [gentoo-dev] rfc: ideas for fixing OpenRC checkpath issue
Date: Wed, 17 Jan 2018 11:14:16 -0600 [thread overview]
Message-ID: <20180117171416.GA18843@whubbs1.gaikai.biz> (raw)
In-Reply-To: <04627c1a-64b7-9370-41d8-ddc79213de5b@gentoo.org>
[-- Attachment #1: Type: text/plain, Size: 2108 bytes --]
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 #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
next prev parent reply other threads:[~2018-01-17 17:14 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-10 0:07 [gentoo-dev] rfc: ideas for fixing OpenRC checkpath issue William Hubbs
2018-01-10 1:19 ` Michael Orlitzky
2018-01-10 18:04 ` William Hubbs
2018-01-10 20:25 ` Michael Orlitzky
2018-01-10 21:54 ` William Hubbs
2018-01-13 20:48 ` Michael Orlitzky
2018-01-17 15:21 ` William Hubbs
2018-01-17 15:41 ` Michael Orlitzky
2018-01-17 17:14 ` William Hubbs [this message]
2018-01-19 0:19 ` Michael Orlitzky
2018-01-20 0:16 ` William Hubbs
2018-01-20 0:53 ` Michael Orlitzky
2018-01-20 1:14 ` William Hubbs
2018-01-20 1:20 ` Michael Orlitzky
2018-01-10 18:17 ` Kristian Fiskerstrand
2018-01-12 16:33 ` Michael Orlitzky
2018-01-10 22:18 ` James Le Cuirot
2018-01-10 23:31 ` Michael Orlitzky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180117171416.GA18843@whubbs1.gaikai.biz \
--to=williamh@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
--cc=mjo@gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox