Re: [gentoo-dev] rfc: ideas for fixing OpenRC checkpath issue

[William Hubbs]

On Wed, Jan 10, 2018 at 03:25:55PM -0500, Michael Orlitzky wrote:
> On 01/10/2018 01:04 PM, William Hubbs wrote:
> > On Tue, Jan 09, 2018 at 08:19:24PM -0500, Michael Orlitzky wrote:
> >
> >> Ultimately, it's not safe to chown/chmod/setfacl/whatever in a directory
> >> that is not writable only by yourself and root.
> >
> > Let me try to phrase this another way.
> >
> > If the directory we are in is not owned by us or root and is group or
> > world writable, checkpath should not change the ownership or permissions
> > of the file passed to it.
>
> There are also POSIX ACLs, NFSv4 ACLs, and god-knows-what-else to worry
> about, but the above is a good start.
>
>
> >> Here's a very tedious proposal for OpenRC: ...
> >>
> >>   2. Have newpath throw a warning if it's used in a directory that is
> >>      writable by someone other than root and the OpenRC user. This will
> >>      prevent people from creating /foo/bar after /foo has already been
> >>      created with owner "foo:foo". In other words, service script
> >>      writers will be encouraged to do things in a safe order. Since
> >>      we're starting over, this might even be made an error.
> >
> > I'm not really a fan of creating a new helper unless I have to; I would
> > rather modify checkpath's behaviour.
> >
> > The first stage of that modification would be to release a version that
> > outputs error messages, then convert the error messages to hard failures
> > in a later release.
> >
> > Is this reasonable? If we go this route, what should checkpath start
> > complaining about?
>
> /*
>  Disclaimer: I'm not even sure that this difficult proposal will solve
>  the problem. Moreover there may be legitimate things going on in some
>  init scripts that I haven't accounted for.
> */
>
> The downside to keeping the name "checkpath" is that it makes it
> difficult to identify unfixed scripts. If we change the name, then "grep
> -rl checkpath" points them out for you; but if checkpath is modified,
> you have to install the package and attempt to start/stop/save/reload it
> and look for warnings.

Good point, this may be a good reason to make a new helper and deprecate
checkpath. What I would do is make checkpath throw an error but keep
running,. It would have a message, something like:

"Checkpath is deprecated, please use newpath instead."

What are we saying newpath should do differently than checkpath if I
go this route?

William