| 1 |
On Tue, Jan 09, 2018 at 08:19:24PM -0500, Michael Orlitzky wrote: |
| 2 |
|
| 3 |
*snip* |
| 4 |
|
| 5 |
> Ultimately, it's not safe to chown/chmod/setfacl/whatever in a directory |
| 6 |
> that is not writable only by yourself and root. |
| 7 |
|
| 8 |
Let me try to phrase this another way. |
| 9 |
|
| 10 |
If the directory we are in is not owned by us or root and is group or |
| 11 |
world writable, checkpath should not change the ownership or permissions |
| 12 |
of the file passed to it. |
| 13 |
|
| 14 |
> Here's a very tedious proposal for OpenRC: |
| 15 |
> |
| 16 |
> 1. Create a new helper, called e.g. "newpath", that is like checkpath |
| 17 |
> but only creates things, and doesn't modify them. |
| 18 |
> |
| 19 |
> 2. Have newpath throw a warning if it's used in a directory that is |
| 20 |
> writable by someone other than root and the OpenRC user. This will |
| 21 |
> prevent people from creating /foo/bar after /foo has already been |
| 22 |
> created with owner "foo:foo". In other words, service script |
| 23 |
> writers will be encouraged to do things in a safe order. Since |
| 24 |
> we're starting over, this might even be made an error. |
| 25 |
> |
| 26 |
> 3. Deprecate checkpath |
| 27 |
> |
| 28 |
> 4. Wait a million years for people to switch from checkpath to newpath |
| 29 |
> |
| 30 |
> 5. Get rid of checkpath |
| 31 |
> |
| 32 |
> I'm not even sure that this solves the problem completely, but it's the |
| 33 |
> only idea I've got left. |
| 34 |
|
| 35 |
I'm not really a fan of creating a new helper unless I have to; I would |
| 36 |
rather modify checkpath's behaviour. |
| 37 |
|
| 38 |
The first stage of that modification would be to release a version that |
| 39 |
outputs error messages, then convert the error messages to hard failures |
| 40 |
in a later release. |
| 41 |
|
| 42 |
Is this reasonable? If we go this route, what should checkpath start |
| 43 |
complaining about? |
| 44 |
|
| 45 |
William |
Archives