On Sat, Jan 13, 2018 at 03:48:10PM -0500, Michael Orlitzky wrote:
> On 01/10/2018 04:54 PM, William Hubbs wrote:
> > 
> > What are we saying newpath should do differently than checkpath if I
> > go this route?
> 
> I think this covers everything that we've talked about:
> 
>  1. It should refuse to modify existing paths.
> 
>     1.a. If newpath is called on an existing path, and if the requested
>          owner/permissions agree with the existing set, then do nothing.
>          This is expected when services restart without a reboot.
> 
>     1.b. If newpath is called on an existing path, and if the desired
>          permissions differ from the existing set, then do nothing and
>          log a warning.
 
 For both A and B above I think you mean owner/group/permissions right?

>  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.)
 
 Checkpath doesn't handle multiple layers of directories currently; you
 can't do "checkpath -d /run/a/b" without doing "checkpath -d /run/a"
 first, so I don't see a way to check parents.

>     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.

William


> And just to put it out there, this will probably make a lot of people
> mad. It discourages you from doing things like setting FOO_USER=foo in
> the conf.d file, because you can't "fix" the permissions on things like
> /var/log/foo.log if the value of $FOO_USER ever changes. That was
> inherently unsafe anyway, but I'll eat my shorts if nobody complains.
> 
> (User variables, or RC_SVCNAME, should still work fine work multiple
> instances.)
> 

Attachment: signature.asc
Description: Digital signature

Reply via email to