public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
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: Fri, 19 Jan 2018 19:14:06 -0600	[thread overview]
Message-ID: <20180120011406.GA25389@linux1.home> (raw)
In-Reply-To: <464a4683-8613-1b79-35a1-9e4d53ae36e6@gentoo.org>

[-- Attachment #1: Type: text/plain, Size: 3190 bytes --]

On Fri, Jan 19, 2018 at 07:53:06PM -0500, Michael Orlitzky wrote:
> On 01/19/2018 07:16 PM, William Hubbs wrote:
> > 
> > It looks like we can't use your --as suggestion if we want to be
> > able to create paths in /var/lib and /var/spool that are owned by
> > non-privileged users because of the permissions on those paths. It is
> > possible that service scripts are doing this.
> > 
> 
> Why not? Since /var/lib is root:root and mode 755, we can create
> /var/lib/foo while running --as=root (the default). Then afterwards,
> anything beneath /var/lib/foo would need to be created "--as" the owner
> of that directory.

That would create an extra level of indirection for some things though,
what if /var/lib/foo needs to be owned by foo? I have /var/lib/dhcp
which is owned by dhcp:dhcp. You can't creat that with --as=dhcp.

> 
> /var/lib or /var/spool should be no different than /run in that regard.
> 
> (Although, the ebuild should be responsible for /var/lib and /var/spool)
> 
> 
> > Is it worth changing the algorithm to do this instead:
> > 
> > 0. test for existance by opening a read-only file descriptor to this
> > file.
> > 1. Creating the file/directory/fifo.
> > a. If it doesn't exist, create it -- note that I'm not setting
> > permissions with the create call.
> > b. Open a read-only file descriptor that attaches to the newly created
> > file.
> > 2. Setting Permissions.
> > a. Fix the permissions of the file if necessary.
> > 3. setting ownership
> > a. Set the ownership if it doesn't match the specified ownership.
> 
> Is this for checkpath? Steps (a) and (b) would need to happen at the
> same time. Is there a way to determine if a file descriptor is for a
> hard link? There are likely some small ways that we could still improve
> checkpath, but the main issue I'm trying to solve by jumping through all
> these hoops is the hard link race condition.

You mean steps 1 (a) and (b)? They would happen in the sequence shown.
The only call that gives you a file descriptor is open() which is not
used to create a directory or a fifo.

The link status is available via fstat() or stat().
An example of checking it is in line 146 of checkpath.c. We refuse to
chmod a file that has more than one hard link to it.

> 
> 
> >> Risk #2: Instead consider a four-component path /run/foo/bar/baz. If you
> >> start creating those directories with owner "foo", then when you get to
> >> creating "baz", it's possible that "bar" has been replaced by a symlink
> >> somewhere else.
> >  
> >  It is possible, sure, but the question I would ask is, could this also
> >  be a legit situation where a user would want /run/foo/bar to be a
> >  symlink to some other location? If it is, there's no way to tell the
> >  difference.
> 
> The init script author can use the real path instead of the one
> involving the symlink if he needs to. So maybe he wants /run/foo/bar to
> be a symlink to /herp/derp, but then instead of doing
> 
>   newpath /run/foo/bar/baz
> 
> he could do
> 
>   newpath /herp/derp/baz
> 
> and then there are no symlinks involved.

Let me think about this... :-)

William

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

  reply	other threads:[~2018-01-20  1: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
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 [this message]
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=20180120011406.GA25389@linux1.home \
    --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