| 1 |
On 02/03/2017 09:51 AM, Martin Vaeth wrote: |
| 2 |
> Michael Orlitzky <mjo@g.o> wrote: |
| 3 |
>> |
| 4 |
>> The fact that all permission and ownership information is shared is |
| 5 |
>> precisely the problem. When you change ownership of the hardlink (which |
| 6 |
>> you'll never know is a hardlink), you change ownership of /etc/shadow. |
| 7 |
> |
| 8 |
> Why should this be a problem except for a race between reading |
| 9 |
> and changing the ownership? |
| 10 |
> Admittedly, by using "find ... -exec ... +" the time for an exploit |
| 11 |
> of the race is even increased when a "standard" chown command is used. |
| 12 |
> |
| 13 |
> However, it is no rocket science to write a race-free chown command |
| 14 |
> in C: Just open the file and use stat() and fchown() to be sure to |
| 15 |
> change only files from the "correct" user. |
| 16 |
> |
| 17 |
> Since this works on the filehandle and not on the filename, I think |
| 18 |
> that there is no possibility for an exploit when this is used in the |
| 19 |
> above find loop. |
| 20 |
|
| 21 |
Not a bad idea... we chould ship that safe-chown utility, and then tell |
| 22 |
users how to use it to fix their UIDs. The draft that I wrote up was for |
| 23 |
the "fixed UID with random fallback" model, but said utility could still |
| 24 |
be useful for people who want to change their running systems to use the |
| 25 |
same UIDs that would have been chosen by default. |
Archives