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