On 28/03/2012 21:28, Paul Eggert wrote:
On 03/28/2012 01:13 PM, Jim Meyering wrote:
$ ./chmod u+w f
./chmod: changing permissions of 'f': Operation not supported
Yeouch. I undid the change for now.
Hmm, why did "make check" work for me?
I'll have to investigate later, alas.
Patch
Paul Eggert wrote:
This fixes what I hope is an obvious race condition
that can occur if some other process substitutes a
symlink for a non-symlink while chmod is running.
Good catch. I'll bet that's exploitable by anyone who
can convince root to run chmod -r ... DIR on files they own.
The
On 03/28/2012 12:36 AM, Jim Meyering wrote:
I presume you'll update NEWS, too, where you can say
[bug introduced in the beginning]
Thanks, good point. I did that in the version I just committed
to the master.
I note also that this doesn't protect anyone who is using
a system that lacks both
Paul Eggert wrote:
On 03/28/2012 12:36 AM, Jim Meyering wrote:
I presume you'll update NEWS, too, where you can say
[bug introduced in the beginning]
Thanks, good point. I did that in the version I just committed
to the master.
I note also that this doesn't protect anyone who is using
a
Paul Eggert wrote:
On 03/28/2012 12:36 AM, Jim Meyering wrote:
I presume you'll update NEWS, too, where you can say
[bug introduced in the beginning]
Thanks, good point. I did that in the version I just committed
to the master.
Rats:
$ ./chmod u+w f
./chmod: changing permissions
On 03/28/2012 01:13 PM, Jim Meyering wrote:
$ ./chmod u+w f
./chmod: changing permissions of 'f': Operation not supported
Yeouch. I undid the change for now.
Hmm, why did make check work for me?
I'll have to investigate later, alas.
This fixes what I hope is an obvious race condition
that can occur if some other process substitutes a
symlink for a non-symlink while chmod is running.
=
* src/chmod.c (process_file): Don't follow symlink if we
think the file is not a symlink.
---
src/chmod.c | 10 +-
1 files
