From: Michael Orlitzky <mjo@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] rfc: ideas for fixing OpenRC checkpath issue
Date: Wed, 17 Jan 2018 10:41:21 -0500 [thread overview]
Message-ID: <04627c1a-64b7-9370-41d8-ddc79213de5b@gentoo.org> (raw)
In-Reply-To: <20180117152108.GA9130@linux1.home>
On 01/17/2018 10:21 AM, William Hubbs wrote:
>
> For both A and B above I think you mean owner/group/permissions right?
Yep.
>> 2. It should have a flag (say, --as=<user>[:group]) to make it run as
>> an unprivileged user. Basically a portable "su -c".
>
> I'm not following why I need this.
>
>> 3. It should die if it's used in a directory that is writable by
>> anyone other than itself or root. (If it's feasible, we might want
>> to check the parent directories all the way up to the root; if I can
>> write to "b", then I can write to "e" in /a/b/c/d/e.)
>
>> Since newpath can't modify existing paths, the aforementioned "--as"
>> flag will be needed to avoid this error.
>
> Which error are you referring to? I don't follow you here. I don't see
> how newpath not modifying existing paths is related to this.
>
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.
next prev parent reply other threads:[~2018-01-17 15:41 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 [this message]
2018-01-17 17:14 ` William Hubbs
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=04627c1a-64b7-9370-41d8-ddc79213de5b@gentoo.org \
--to=mjo@gentoo.org \
--cc=gentoo-dev@lists.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