Re: Kernel 3.14.x bug? rm, mv root-owned files
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 06/08/2014 08:58 PM, Bob Proulx wrote:
> The Wanderer wrote:
>> Yes, moving a file affects only data stored in the directory node
>> which contains the file (and the directory node where the file is
>> being moved to, which may be the same one).
>>
>> But deleting a file does not affect only data stored in the
>> directory node which contains the file; it affects data stored in
>> the file itself. (Assuming that there is only one hardlink to the
>> file and the file is not presently open in any currently running
>> process, which is often a reasonable assumption - and even when it
>> is not, I don't think the permissions behavior of 'rm' should be
>> different depending on the number of hardlinks to the file.)
By this, I meant that I think 'rm' should refuse permission to remove a
particular hardlink to the file when there are multiple such hardlinks,
just as I think it should when there is only one.
> Think of the case I presented above. Let's change it slightly.
>
> mkdir /tmp/testdir1 /tmp/testdir2
> date -R >/tmp/testdir1/testfile1
> ln /tmp/testdir1/testfile1 /tmp/testdir2/testfile2
> md5sum /tmp/testdir1/testfile1 /tmp/testdir2/testfile2
> 16dccbc3809d0e5051f1b73bf9ca5687 /tmp/testdir1/testfile1
> 16dccbc3809d0e5051f1b73bf9ca5687 /tmp/testdir2/testfile2
> ls -ldog /tmp/testdir1/testfile1 /tmp/testdir2/testfile2
> -rw-rw-r-- 2 32 Jun 8 18:32 /tmp/testdir1/testfile1
> -rw-rw-r-- 2 32 Jun 8 18:32 /tmp/testdir2/testfile2
> chmod a-w /tmp/testdir2/testfile2
> ls -ldog /tmp/testdir1/testfile1 /tmp/testdir2/testfile2
> -r--r--r-- 2 32 Jun 8 18:32 /tmp/testdir1/testfile1
> -r--r--r-- 2 32 Jun 8 18:32 /tmp/testdir2/testfile2
>
> Only one chmod needed because there really is only one file. There
> are two links.
Yes - in fact, I tested this myself the other day, while investigating
this question.
> Now how should it be handled if you remove one?
>
> rm -f /tmp/testdir1/testfile1
>
> That must work. Right? Because we have not actually deleted the
> file. Not yet anyway. The file is still there. The file hasn't
> been modified at all.
I disagree that this "must work", in fact. I would say that this should
not work, because...
> ls -ldog /tmp/testdir2/testfile2
> -r--r--r-- 1 32 Jun 8 18:32 /tmp/testdir2/testfile2
> md5sum /tmp/testdir2/testfile2
> 16dccbc3809d0e5051f1b73bf9ca5687 /tmp/testdir2/testfile2
>
> So if the paradigm you are exploring existed the above would be
> allowed. But now unlinking the testfile2 case would not be allowed.
...of this.
> rm -f /tmp/testdir2/testfile2
>
> In the case you are exploring the above would fail because it was the
> last reference to the file. It is only at that time that the file
> would actually be freed. There just isn't any reasonable way to make
> the behavior consistent between the case where the file has
> additional links to it and the case when they don't. And the whole
> purpose of links is to be transparent. Causing different behavior
> would defeat much of the purpose of hard links.
I agree that this behavior must be consistent.
I simply believe that it should be consistent by refusing the deletion
in both cases, rather than allowing it in both cases.
The only case I can see where this would seem to cause problems is in
the handling of 'rm -f', i.e. overriding the permission flag. In that
scenario, I don't think it would be unreasonable to consult
file-ownership information (possibly including group information) to
determine whether to allow the override.
I'll admit that the ramifications of that (e.g, do we allow deletion by
group members, or not?) would start to get complicated enough that
trying to make them general and consistent might effectively involve a
reimplementation of ACLs, though.
I think this change (which was my original intent) to the proposed
paradigm would eliminate the "last reference count is an open file
descriptor" problem, because in that situation it could continue to work
just the way it currently does: if the last open file descriptor is
closed when there are no filesystem links to the file node, the file is
removed. The only difference would be that the last filesystem link
could be removed only by someone who has write permission to the file,
rather than someone who has write permission to the directory containing
the last filesystem link.
>> As such, it seems as if deleting a file *should* require write
>> permission to that file.
>
> I agree that it *feels* like a read-only file should never be
> possible to be freed. But there isn't any practical way to make that
> happen.
I'm afraid I don't see why. (Barring the 'rm -f' handling issue
mentioned above. It might be argued that permitting override of the
permissions flag it itself the origin of this problem.)
What I specifically think should be possible, which doesn't seem to be
possible under the apparent current paradigm, is a situation where there
is a directory in which user A can create new files and modify those
files but in which there is a file which user A cannot delete. Maybe
that could be done through group permissions and the like, I haven't
experimented, but I wouldn't expect that based on discussion so far.
> And it is worse for root. Root always has write permission even if
> the file does not have write bits. The superuser has super user
> permissions.
Of course. That would simply mean that root is always allowed to delete
the file; I don't see any problem with that in the model I propose.
- --
The Wanderer
Secrecy is the beginning of tyranny.
A government exists to serve its citizens, not to control them.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBCgAGBQJTlZoOAAoJEASpNY00KDJrJ/4P/3Fkb9dN/naieUsbCdkBz3we
CSoPU2kOWVuGIzGeeC7qJgcBM8csl/0Aq0jTR57pzdfQ09jJ9Tw6SQPOuuZluwZG
PQqwuA01csuygzBX821Bk4VIlNMtYkTGpIB6t0jTjEPtUsf6FnC+3dMjSmqfT6yS
n7VoRx1pxBf+QcAtkd9wGRM7pfGZ65OOwhMqlx8RH3Q7miTUCvn/xlHPuw7mCJwd
WVDs+5MC5c5RLwBCjD5kiIpubZ40FNbmsJjrvzfv9hVDZoP3mTgPnsCAzBwSRfQ0
wCVXQgHVYgH8iFkE0jIlWkDpZNFHp8Ux7b/AZWxaCBPjPOeaibgVJUGzUIn+GTGm
Pbkzc2B0tCojp/zJFQr1oP3MZWexudGKK/2fRh0hO/o5Hf6jiNjoTmfDpjbzBE0B
F67o9G/Jw5xEGGyC1L87Ck8EYB2LBwt/r0yzHpNe1nbDfvKnWH7SP6MVbPNzOz/r
KVFHDQJjc+WxZFM9Tf9/buhTpWLcJP26WRFSeig8fNfPs7mQFmmjAblFXYzT9Gsx
gwLHP1guJ4zr352Phtj1h0JiOhUi9oCDQswyuUXUjYSl0vN4B5Zu4jrtAKCuJrK3
C+jap40UqB0BFMFygdsQQbEBpoSk6C5PRfNKW4++LDHODHK5KiVFvcBcLH0JPBT/
P8R1Wl0mS59C1Lwj4td3
=y69f
-----END PGP SIGNATURE-----
Reply to: