On 12/20/2017 10:43 PM, Michael Orlitzky wrote:
When calling chown recursively, there is an "obvious" race condition
that is handled correctly:
$ sudo mkdir -p foo/bar
$ sudo chown --verbose --recursive mjo foo
changed ownership of 'foo/bar' from root to mjo
changed ownership of 'foo' from root to mjo
If the order was switched, there would be a period of time where mjo
could do bad things in "foo" before chown operated on its contents. But
so far so good: the order above is safe, and "chown -R" won't follow
symlinks by default.
Can we screw things up by dereferencing symlinks? I think so.
[...]
The depth-first traversal follows the symlink and changes ownership of
foo/quux (which points to bar) before it changes ownership of bar/baz.
Note that the "--dereference" flag implies the same problem. It forces
you to set either "-H" or "-L", and in that context, choosing "-H" won't
prevent the link itself from being dereferenced (notabug 29788).
But what to do about it? I'm not sure... would doing the traversal
depth-first with respect to realpath help?
Doesn't the same problem exist in the other direction as well?
I mean if you change the ownership of a directory hierarchy from
user A to user B, then both A and B could try to place malicious
symlinks during the processing. That means depth-first minimizes
the problem regarding the receiving user B but may widen the race
window for user A.
> I
> think you're asking for trouble when you follow links OR when you
> operate recursively,
+1
> but "-R -L" is POSIX, so I guess we make the best
> of it.
The safest way is to add the --from option in order to ensure (with
the most tiny race window) that still user A is the owner:
$ sudo chown -v --from=A B file
ownership of 'file' retained as A
Have a nice day,
Berny
