| 1 |
On Sat, Jan 13, 2018 at 03:48:10PM -0500, Michael Orlitzky wrote: |
| 2 |
> On 01/10/2018 04:54 PM, William Hubbs wrote: |
| 3 |
> > |
| 4 |
> > What are we saying newpath should do differently than checkpath if I |
| 5 |
> > go this route? |
| 6 |
> |
| 7 |
> I think this covers everything that we've talked about: |
| 8 |
> |
| 9 |
> 1. It should refuse to modify existing paths. |
| 10 |
> |
| 11 |
> 1.a. If newpath is called on an existing path, and if the requested |
| 12 |
> owner/permissions agree with the existing set, then do nothing. |
| 13 |
> This is expected when services restart without a reboot. |
| 14 |
> |
| 15 |
> 1.b. If newpath is called on an existing path, and if the desired |
| 16 |
> permissions differ from the existing set, then do nothing and |
| 17 |
> log a warning. |
| 18 |
|
| 19 |
For both A and B above I think you mean owner/group/permissions right? |
| 20 |
|
| 21 |
> 2. It should have a flag (say, --as=<user>[:group]) to make it run as |
| 22 |
> an unprivileged user. Basically a portable "su -c". |
| 23 |
|
| 24 |
I'm not following why I need this. |
| 25 |
|
| 26 |
> 3. It should die if it's used in a directory that is writable by |
| 27 |
> anyone other than itself or root. (If it's feasible, we might want |
| 28 |
> to check the parent directories all the way up to the root; if I can |
| 29 |
> write to "b", then I can write to "e" in /a/b/c/d/e.) |
| 30 |
|
| 31 |
Checkpath doesn't handle multiple layers of directories currently; you |
| 32 |
can't do "checkpath -d /run/a/b" without doing "checkpath -d /run/a" |
| 33 |
first, so I don't see a way to check parents. |
| 34 |
|
| 35 |
> Since newpath can't modify existing paths, the aforementioned "--as" |
| 36 |
> flag will be needed to avoid this error. |
| 37 |
|
| 38 |
Which error are you referring to? I don't follow you here. I don't see |
| 39 |
how newpath not modifying existing paths is related to this. |
| 40 |
|
| 41 |
William |
| 42 |
|
| 43 |
|
| 44 |
> And just to put it out there, this will probably make a lot of people |
| 45 |
> mad. It discourages you from doing things like setting FOO_USER=foo in |
| 46 |
> the conf.d file, because you can't "fix" the permissions on things like |
| 47 |
> /var/log/foo.log if the value of $FOO_USER ever changes. That was |
| 48 |
> inherently unsafe anyway, but I'll eat my shorts if nobody complains. |
| 49 |
> |
| 50 |
> (User variables, or RC_SVCNAME, should still work fine work multiple |
| 51 |
> instances.) |
| 52 |
> |
Archives