Re: Kernel 3.14.x bug? rm, mv root-owned files
The Wanderer wrote: 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. Hmm... That would be a completely different operating model. A valid model could be constructed that operates differently. But that wouldn't be the file system behavior model that we have been using for the last forty years. 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... ... 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. That is quite a harsh restriction. It basically removes much of the functionality that has been added by file links (hard links). A lot of things depend upon being able to make a hard link to a file and then when the file is removed from the original directory it remains behind in the other places the file is linked. A lot of backup programs rely upon this (BackupPC, many others). A lot of deployment programs (stow). It is just one of those fundamental constructs that has been there since the beginning that so many things rely upon. Taking that away would cause a lot of lost functionality breakage. 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. The 'rm' command is a little odd for Unix in that it actually stats the file before removing it and if the file is read-only then it helpfully questions the user first for the verification. All the option flag -f does is avoid the stat and just attempt the unlink(2) system call without asking. That only an 'rm' command line thing. If you try this from perl, python, ruby, others then there isn't any user interaction at all. Try this on a read-only file. touch testfile1 chmod a-w testfile1 ls -ldog testfile1 -r--r--r-- 1 0 Jun 12 15:17 testfile1 perl -e 'unlink(%s\n,$ARGV[0]) or die;' testfile1 ls -ldog testfile1 ls: cannot access testfile1: No such file or directory Note that the rm question is a feature of rm and not unlink(2). Programs unlinking files just unlink the file and there isn't any questions asked about it. There isn't really any concept in rm of overriding the permission flag. It just avoids being helpful in that case. Helpful being relative. Also there is a race condition of sorts. In rm when it stat(2)s the file first it then proceeds to unlink(2) the file. That is two separate system calls. In between those two calls it is possible to chmod the file, or unlink the file, or other things to the file. The use of two system calls back to back is not atomic. It is by its nature a race with other actions. It is possible to confuse the command by changing things between. Removing the stat(2) call with -f does avoid that race by avoiding the stat entirely. And speeds things up too if there are a lot of files or if the files are over NFS or other remote system. 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. Have you ever used AFS? The permissions are all ACL based. And the point I have here is that it is a different security model. A re-implementation using ACLs. http://docs.openafs.org/UserGuide/HDRWQ46.html You might like that security model better. It is different from the classic Unix file system model. The problem is that most software expects the traditional Unix file system permisssions and often requires modification to operate on an AFS system. Or it did when last I used AFS many years ago. 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. If it had been that way at the beginning when the file system implemented the behavior then I would probably be fine with it. Because then that would be the way
Re: Kernel 3.14.x bug? rm, mv root-owned files
On Fri, Jun 06, 2014 at 04:45:37PM +0200, Filip wrote: Removing a directory entries no relation whatsoever to the permissions of the file. Parse error! Does not compute! :) -- If you're not careful, the newspapers will have you hating the people who are being oppressed, and loving the people who are doing the oppressing. --- Malcolm X -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140609060227.GG21959@tal
Re: Kernel 3.14.x bug? rm, mv root-owned files
Chris Bannister cbannis...@slingshot.co.nz writes:
On Fri, Jun 06, 2014 at 04:45:37PM +0200, Filip wrote:
Removing a directory entries no relation whatsoever to the permissions
of the file.
Parse error! Does not compute! :)
--
If you're not careful, the newspapers will have you hating the people
who are being oppressed, and loving the people who are doing the
oppressing. --- Malcolm X
What I mean to say was: The permissions on the file have no bearing on
whether or not you can unlink it's directory entry.
But really, it's a white lie ;-)
Because, it's possible to set the 'immutable' attribute ('chattr +i') on
the file which will prevent anyone from linking or unlinking the file,
and also prevents all write operations. But that is not really part of
the regular permission system, but more of a file system feature. And
it's not something to be casually used by end-users because a regular
user can't change the attribute.
Let's create a file and set the +i attribute:
$ touch imm
$ chattr +i imm
chattr: Operation not permitted while setting flags on imm
$ ls -l imm
-rw-r--r-- 1 filip filip 0 Jun 9 10:37 imm
$ sudo chattr +i imm
$ lsattr imm
ie-- imm
Permissions on the file on on the containing directory look quite
ordinary:
$ ls -ld .
drwxr-xr-x 2 filip filip 4096 Jun 9 09:57 .
$ ls -ld imm
-rw-r--r-- 1 filip filip 0 Jun 9 09:47 imm
Now let's try some operations:
$ echo test imm
bash: imm: Permission denied
$ mv imm newname
mv: cannot move ‘imm’ to ‘newname’: Operation not permitted
$ rm imm
rm: remove write-protected regular empty file ‘imm’? y
rm: cannot remove ‘imm’: Operation not permitted
$ ln imm newlink
ln: failed to create hard link ‘newlink’ = ‘imm’: Operation not permitted
We are not allowed to do very much with it.
Well at least reading works:
$ cat imm
$
It's an empty file, so the content is not very exciting, but try it
yourself with a file that contains data if you don't believe me ;-)
Now remove the attribute:
$ chattr -i imm
chattr: Operation not permitted while setting flags on imm
$ sudo chattr -i imm
$ lsattr imm
-e-- imm
And now we can remove the file:
$ rm imm
$ ls imm
ls: cannot access imm: No such file or directory
pgpawpkSLt_Dq.pgp
Description: PGP signature
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
Re: Kernel 3.14.x bug? rm, mv root-owned files
The Wanderer wrote: Bob Proulx wrote: jimmy wrote: // --- remove (delete) a file owned by root, should not be allowed, but is allowed. Here, it says the file is 'read-only' so it warns about it, but of course rm -f would work, too: Why do you think it should not be allowed? It is allowed. If you don't want a user to modify the directory then change the permissions of the directory. In this case, however, the user isn't just modifying the directory; the user is modifying a file in the directory, by deleting that file. Deleting a file does not modify the file contents. Really! :-) Try this: 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 Obviously at that time there will appear to be two files with the same contents. I say appear to be two files because it is one file that is linked in two places. But there is really only one file. Now remove one file. We would say unlink that file. man 2 unlink The reason you unlink a file to remove it is due to the above situation. Removing a file simply unlinks it from a directory. rm /tmp/testdir1/testfile1 Okay. It is gone. It is removed from /tmp/testdir1. Was the file modified? Let's check the file. md5sum /tmp/testdir2/testfile2 16dccbc3809d0e5051f1b73bf9ca5687 /tmp/testdir2/testfile2 No modification was made to the file by removing it from the directory. And then as others pointed out the file system is reference counted. When the reference count to a file is reduced to zero then the space is actually freed. As long as the reference count is non-zero the file is not modified by removing it (unlinking it) from a directory. Therefore you do not need write permission to a file to remove it. You need write permission to the directory holding it. $ rm -v /tmp/testing/newjunk1.txt rm: remove write-protected regular file ‘/tmp/testing/newjunk1.txt’? y removed ‘/tmp/testing/newjunk1.txt’ Sure. Because tst1 owns /tmp/testing. I'm confused as to why that's enough. I mis-wrote the above when I said it was because tst1 owns /tmp/testing. I had tried to be careful about talking about permissions elsewhere. But I had originally written my response saying owns. I went back and edited my response and changed most of those to write permission but missed that one. You caught me there on the one I missed editing. I should have said because tst1 has write permission to the directory. 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.) 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. 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. 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. 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
Re: Kernel 3.14.x bug? rm, mv root-owned files
On Thu, 5 Jun 2014, Bob Proulx wrote: jimmy wrote: Could anyone verify this bug I ran into, please? I don't know for sure if it is the new kernel, or any combination of various packages (pam, rm, mv...). I see no bug here. OP, your experiments uncover an important feature of directory ownership: the get off my lawn property. What would lawn-ownership even mean, if you couldn't kick stuff/solicitors/dogs off of it, call them funny names, etc? -wes -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/alpine.deb.2.02.1406060311390.10...@brutus.ling.ohio-state.edu
Re: Kernel 3.14.x bug? rm, mv root-owned files
On 2014-06-06, wes david...@ling.ohio-state.edu wrote: OP, your experiments uncover an important feature of directory ownership: the get off my lawn property. Don't you mean the Get off my my property, Lon, property? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/slrnlp2ujm.22m.cu...@einstein.electron.org
Re: Kernel 3.14.x bug? rm, mv root-owned files
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 06/05/2014 11:37 PM, Bob Proulx wrote: jimmy wrote: // --- remove (delete) a file owned by root, should not be allowed, but is allowed. Here, it says the file is 'read-only' so it warns about it, but of course rm -f would work, too: Why do you think it should not be allowed? It is allowed. If you don't want a user to modify the directory then change the permissions of the directory. In this case, however, the user isn't just modifying the directory; the user is modifying a file in the directory, by deleting that file. $ rm -v /tmp/testing/newjunk1.txt rm: remove write-protected regular file ‘/tmp/testing/newjunk1.txt’? y removed ‘/tmp/testing/newjunk1.txt’ Sure. Because tst1 owns /tmp/testing. I'm confused as to why that's enough. 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.) As such, it seems as if deleting a file *should* require write permission to that file. Is there something I'm missing here? - -- 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/ iQIcBAEBCgAGBQJTkcU7AAoJEASpNY00KDJrASoQAJvzGvZm06gvesZxnnG+mZBp 5IcU4rgQP2JYXdNP+Q69aq/tCgAo695NIrwXFyzOeIrhvsnxOs65dc0ofe8W Vz8Voyx7d40Xtz5p80ngdCbqI353fCBkt3dzFwjIBaNJjj/ltn5V5orR6cEvcI53 0hwa7CZ9deKim0yon/PpKBY3bFYF55BT9czszBGC9UjMoi8gaSfGz27hbEKe6dOi mRdz3CQcdKZgKQClJBVkvCx+DrTSSy6K82LvtyuH1NyEf+Cn1SL215RsWEZkrXD9 W2qqDGj6GjuaTIc8EqI4CcNS+RaSH6K6gtXKdcmFkfIZadNL+CrTvT5G9upcm9fa bcSCOnLYke0ieI1e4aZHLruY8IjRvVzsWs3a86AUt3+OvNRneiiqHMFycTm6OUsn K4VP+Mn95Kc3DLhaTozM4a5ATxVwPsidAR4M01c9wMQ4mCy+ReCY88MPyJD6C6pT CIA2Zv+kC7zb3Bwvfgu2LqylIE8EzoFrUMtyc1Nq7PSaRRdmrlfFEILGmttocUcZ ns894dQK4mSMPFnhKsOjNaXtNQBtmoGPsiXiDSR+2DhAPv9upyHpYAv4BHZ77WFk 59Z8wkKLLJLNLk/7DrZYG+eWzpbvebwhxfTVZuv5OUJmaGPFoz0LL/i340pYnCBj CGixggwiQE/Clc4fBzk9 =GjkX -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5391c53b.4080...@fastmail.fm
Re: Kernel 3.14.x bug? rm, mv root-owned files
Ahoj, Dňa Fri, 06 Jun 2014 09:42:19 -0400 The Wanderer wande...@fastmail.fm napísal: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 06/05/2014 11:37 PM, Bob Proulx wrote: jimmy wrote: // --- remove (delete) a file owned by root, should not be allowed, but is allowed. Here, it says the file is 'read-only' so it warns about it, but of course rm -f would work, too: Why do you think it should not be allowed? It is allowed. If you don't want a user to modify the directory then change the permissions of the directory. In this case, however, the user isn't just modifying the directory; the user is modifying a file in the directory, by deleting that file. I understand your confusion. I was confused by the same way a lot years ago, when i come from Windows, where the RO attribute disallows to delete the file. You need to consider, that in Linux (or more precise, on Unix based systems) all is a file, where on filesystem: - file has its content and attributes - directory has it content and attributes too (because it is a file) (The attributes here are in mean access/modify times and access rights) The content of the file are file's bytes, e.g. letters in text file. But not the file itself. The file itself is nothing other, than pointer to place on the storage device (simplified) and this pointer is a content of the correspondent directory (where file is placed). You need to know, that the deleting of the file is not removing the bytes from storage, but only removing this pointer from directory. By things mentioned above, access right allow or not allow (beside others) to access/modify the content of the file and/or modify the content of the directory (remember you? - it is a file too). Deleting the file is removing pointer to it from it's correspondent directory, thus modifying the content of the directory, because directory's file (pointer to place on the disk) is a part of the directory, not a file of itself, then not file's rights are here in the play but the directory's rights. regards -- Slavko http://slavino.sk signature.asc Description: PGP signature
Re: Kernel 3.14.x bug? rm, mv root-owned files
The Wanderer wande...@fastmail.fm writes: On 06/05/2014 11:37 PM, Bob Proulx wrote: jimmy wrote: // --- remove (delete) a file owned by root, should not be allowed, but is allowed. Here, it says the file is 'read-only' so it warns about it, but of course rm -f would work, too: Why do you think it should not be allowed? It is allowed. If you don't want a user to modify the directory then change the permissions of the directory. In this case, however, the user isn't just modifying the directory; the user is modifying a file in the directory, by deleting that file. $ rm -v /tmp/testing/newjunk1.txt rm: remove write-protected regular file ‘/tmp/testing/newjunk1.txt’? y removed ‘/tmp/testing/newjunk1.txt’ Sure. Because tst1 owns /tmp/testing. I'm confused as to why that's enough. 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.) As such, it seems as if deleting a file *should* require write permission to that file. I makes perfect sense to me. rm doesn't actually delete files. It unlinks a directory entry. If this was the last link to the inode that constitutes the file (no links in other directories an no open file handles), the inode is deleted as a side effect. Removing a directory entries no relation whatsoever to the permissions of the file. Is there something I'm missing here? -- The Wanderer Secrecy is the beginning of tyranny. A government exists to serve its citizens, not to control them. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/8761ke2j1q@orac.fil
Kernel 3.14.x bug? rm, mv root-owned files
Hello, Could anyone verify this bug I ran into, please? I don't know for sure if it is the new kernel, or any combination of various packages (pam, rm, mv...). Thanks, Jimmy ###- Software version: kernel 3.14.5 Debian sid Problem description: With normal/common file permission usage, in a directory owned by non-root user, the user can rename or delete root-owned files using: /bin/mv /bin/rm Within such directory, that non-root user can also /bin/rm, or /bin/mv an empty root-owned subdirectory /bin/mv a subdirectory owned by root but prevented from moving or deleting the files within such subdirectory ###- Some tests: As user 'tst1': $ mkdir -p /tmp/testing/ $ ls -altr /tmp | grep testing drwxr-xr-x 2 tst1 tst1 4096 Jun 5 13:48 testing As root, create some files and subdirectory in the above directory: # echo 1 2 3 4 5 /tmp/testing/test1.txt # ls -altr /tmp/testing/ total 12 drwxrwxrwt 14 root root 4096 Jun 5 13:48 .. -rw-r--r-- 1 root root 10 Jun 5 13:49 test1.txt drwxr-xr-x 2 tst1 tst1 4096 Jun 5 13:49 . # mkdir -p /tmp/testing/test.mvrmBug/ # ls -altr /tmp/testing/ total 16 drwxrwxrwt 14 root root 4096 Jun 5 13:48 .. -rw-r--r-- 1 root root 10 Jun 5 13:49 test1.txt drwxr-xr-x 2 root root 4096 Jun 5 13:50 test.mvrmBug drwxr-xr-x 3 tst1 tst1 4096 Jun 5 13:50 . # echo a b c d e /tmp/testing/test.mvrmBug/test2.txt # ls -altr /tmp/testing/test.mvrmBug/ total 12 drwxr-xr-x 3 tst1 tst1 4096 Jun 5 13:50 .. -rw-r--r-- 1 root root 10 Jun 5 13:51 test2.txt drwxr-xr-x 2 root root 4096 Jun 5 13:51 . # mkdir -p /tmp/testing/test.mvrmEmptySubdir/ # ls -altr /tmp/testing/ total 20 drwxrwxrwt 14 root root 4096 Jun 5 13:48 .. -rw-r--r-- 1 root root 10 Jun 5 13:49 test1.txt drwxr-xr-x 2 root root 4096 Jun 5 13:51 test.mvrmBug drwxr-xr-x 2 root root 4096 Jun 5 13:52 test.mvrmEmptySubdir drwxr-xr-x 4 tst1 tst1 4096 Jun 5 13:52 . As the original user 'tst1': $ ls -altr /tmp/ | grep testing drwxr-xr-x 4 tst1 tst1 4096 Jun 5 13:52 testing $ ls -altr /tmp/testing/ total 20 drwxrwxrwt 14 root root 4096 Jun 5 13:48 .. -rw-r--r-- 1 root root 10 Jun 5 13:49 test1.txt drwxr-xr-x 2 root root 4096 Jun 5 13:51 test.mvrmBug drwxr-xr-x 2 root root 4096 Jun 5 13:52 test.mvrmEmptySubdir drwxr-xr-x 4 tst1 tst1 4096 Jun 5 13:52 . // --- rename (move) a file owned by root, should not be allowed, but is allowed: $ mv -v /tmp/testing/test1.txt /tmp/testing/junk1.txt ‘/tmp/testing/test1.txt’ - ‘/tmp/testing/junk1.txt’ $ ls -altr /tmp/testing/ total 20 drwxrwxrwt 14 root root 4096 Jun 5 13:48 .. -rw-r--r-- 1 root root 10 Jun 5 13:49 junk1.txt drwxr-xr-x 2 root root 4096 Jun 5 13:51 test.mvrmBug drwxr-xr-x 2 root root 4096 Jun 5 13:52 test.mvrmEmptySubdir drwxr-xr-x 4 tst1 tst1 4096 Jun 5 13:53 . $ mv -v /tmp/testing/junk1.txt /tmp/testing/newjunk1.txt ‘/tmp/testing/junk1.txt’ - ‘/tmp/testing/newjunk1.txt’ $ ls -altr /tmp/testing/ total 20 -rw-r--r-- 1 root root 10 Jun 5 13:49 newjunk1.txt drwxr-xr-x 2 root root 4096 Jun 5 13:51 test.mvrmBug drwxr-xr-x 2 root root 4096 Jun 5 13:52 test.mvrmEmptySubdir drwxrwxrwt 14 root root 4096 Jun 5 13:55 .. drwxr-xr-x 4 tst1 tst1 4096 Jun 5 13:55 . // --- remove (delete) a file owned by root, should not be allowed, but is allowed. Here, it says the file is 'read-only' so it warns about it, but of course rm -f would work, too: $ rm -v /tmp/testing/newjunk1.txt rm: remove write-protected regular file ‘/tmp/testing/newjunk1.txt’? y removed ‘/tmp/testing/newjunk1.txt’ $ ls -altr /tmp/testing/ total 16 drwxr-xr-x 2 root root 4096 Jun 5 13:51 test.mvrmBug drwxr-xr-x 2 root root 4096 Jun 5 13:52 test.mvrmEmptySubdir drwxrwxrwt 14 root root 4096 Jun 5 13:55 .. drwxr-xr-x 4 tst1 tst1 4096 Jun 5 13:57 . // --- rename (move) a subdirectory owned by root, should not be allowed, but is allowed: $ mv -v /tmp/testing/test.mvrmBug /tmp/testing/try.mvrmBug ‘/tmp/testing/test.mvrmBug’ - ‘/tmp/testing/try.mvrmBug’ $ ls -altr /tmp/testing/ total 16 drwxr-xr-x 2 root root 4096 Jun 5 13:51 try.mvrmBug drwxr-xr-x 2 root root 4096 Jun 5 13:52 test.mvrmEmptySubdir drwxrwxrwt 14 root root 4096 Jun 5 13:55 .. drwxr-xr-x 4 tst1 tst1 4096 Jun 5 14:00 . $ mv -v /tmp/testing/try.mvrmBug /tmp/testing/squash.mvrmBug ‘/tmp/testing/try.mvrmBug’ - ‘/tmp/testing/squash.mvrmBug’ $ ls -altr /tmp/testing/ total 16 drwxr-xr-x 2 root root 4096 Jun 5 13:51 squash.mvrmBug drwxr-xr-x 2 root root 4096 Jun 5 13:52 test.mvrmEmptySubdir drwxrwxrwt 14 root root 4096 Jun 5 13:55 .. drwxr-xr-x 4 tst1 tst1 4096 Jun 5 14:01 . // --- can delete (rmdir, rm -fR, rm -fr) an empty subdirectory, did not even prompt for confirmation, should not be allowed: $ rmdir -v /tmp/testing/test.mvrmEmptySubdir/ rmdir: removing directory,
Re: Kernel 3.14.x bug? rm, mv root-owned files
On Thu, 2014-06-05 at 17:39 -0700, jimmy wrote: Problem description: With normal/common file permission usage, in a directory owned by non-root user, the user can rename or delete root-owned files using: /bin/mv /bin/rm Within such directory, that non-root user can also /bin/rm, or /bin/mv an empty root-owned subdirectory /bin/mv a subdirectory owned by root but prevented from moving or deleting the files within such subdirectory Well that's just normal if the user owns that parent dir. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Re: Kernel 3.14.x bug? rm, mv root-owned files
jimmy wrote: Could anyone verify this bug I ran into, please? I don't know for sure if it is the new kernel, or any combination of various packages (pam, rm, mv...). I see no bug here. $ mkdir -p /tmp/testing/ $ ls -altr /tmp | grep testing drwxr-xr-x 2 tst1 tst1 4096 Jun 5 13:48 testing Please look at the ls -d option instead of using grep. :-) $ ls -ld /tmp/testing drwxr-xr-x 2 tst1 tst1 4096 Jun 5 13:48 testing As root, create some files and subdirectory in the above directory: # echo 1 2 3 4 5 /tmp/testing/test1.txt # mkdir -p /tmp/testing/test.mvrmBug/ It is okay to have the trailing slash there but it isn't normal to have it present. # echo a b c d e /tmp/testing/test.mvrmBug/test2.txt # mkdir -p /tmp/testing/test.mvrmEmptySubdir/ ... As the original user 'tst1': // --- rename (move) a file owned by root, should not be allowed, but is allowed: $ mv -v /tmp/testing/test1.txt /tmp/testing/junk1.txt ‘/tmp/testing/test1.txt’ - ‘/tmp/testing/junk1.txt’ There is no bug there. What makes you think it isn't allowed? You have write permission to the /tmp/testing directory. Therefore you can move or rename or remove any file from it. The owner of the file entry you are renaming or moving is not relevant. You are not changing the file. You are changing the directory. You have write permission to the directory. Therefore you can modify the directory. You also own the directory too but that just means that if you don't have write permission you can chmod it so that you do. Try another experiment and chmod the directory that you own so that you don't have write permission to it any longer. Then try to modify the directory. It will fail with a permission denied message. $ mv -v /tmp/testing/junk1.txt /tmp/testing/newjunk1.txt ‘/tmp/testing/junk1.txt’ - ‘/tmp/testing/newjunk1.txt’ Same thing. You can write to the /tmp/testing directory and therefore can modify it. Note that when you move files like that you are not modifying the file. You are modifying the directory which has an entry pointing to the file. The file itself is unchanged. You can see this by removing write permission to the file. // --- remove (delete) a file owned by root, should not be allowed, but is allowed. Here, it says the file is 'read-only' so it warns about it, but of course rm -f would work, too: Why do you think it should not be allowed? It is allowed. If you don't want a user to modify the directory then change the permissions of the directory. For example as your tst1 user try to move a file out of /usr/bin. Any file in /usr/bin. You will find that it is not possible to move files out of /usr/bin as the tst1 user because the tst1 user has no write permission to the /usr/bin directory. $ rm -v /tmp/testing/newjunk1.txt rm: remove write-protected regular file ‘/tmp/testing/newjunk1.txt’? y removed ‘/tmp/testing/newjunk1.txt’ Sure. Because tst1 owns /tmp/testing. You would want a user to be unable to modify a file that they have write permission to modify? That would clearly be a bug if the user were not allowed to write to files that they have permission to write to. (Directories are simply files in the Unix file system model. Directories are special files. But files just the same.) // --- rename (move) a subdirectory owned by root, should not be allowed, but is allowed: You keep saying should not be allowed. Why not? It should be allowed. You own the directory. $ mv -v /tmp/testing/test.mvrmBug /tmp/testing/try.mvrmBug ‘/tmp/testing/test.mvrmBug’ - ‘/tmp/testing/try.mvrmBug’ Same thing here. $ mv -v /tmp/testing/try.mvrmBug /tmp/testing/squash.mvrmBug ‘/tmp/testing/try.mvrmBug’ - ‘/tmp/testing/squash.mvrmBug’ Likewise. // --- can delete (rmdir, rm -fR, rm -fr) an empty subdirectory, did not even prompt for confirmation, should not be allowed: Stop saying should not be allowed since that is incorrect. Instead simply ask, This is doing something I don't understand. Can someone please explain to me why this behavior is occurring? Because obviously it is working that way. After 40 years if it were a problem then by now surely someone else would have noticed first. :-) $ rmdir -v /tmp/testing/test.mvrmEmptySubdir/ rmdir: removing directory, ‘/tmp/testing/test.mvrmEmptySubdir/’ Sure. Looks good. If you couldn't then that would be a bug. // --- at least, cannot remove, or reach inside a not-empty subdirectory owned by root, thank goodness: $ rm -fR /tmp/testing/squash.mvrmBug rm: cannot remove ‘/tmp/testing/squash.mvrmBug/test2.txt’: Permission denied Now you are trying to remove a file from /tmp/testing/squash.mvrmBug but you as the tst1 user do not have write permission to that directory. Therefore permission is denied. It really isn't a question of ownership of the directory. It is whether you have write permission to it. For an additional homework assignment look
Re: Kernel 3.14.x bug? rm, mv root-owned files
On Fri, Jun 6, 2014 at 1:37 PM, Bob Proulx b...@proulx.com wrote: $ rm -v /tmp/testing/newjunk1.txt rm: remove write-protected regular file ‘/tmp/testing/newjunk1.txt’? y removed ‘/tmp/testing/newjunk1.txt’ Sure. Because tst1 owns /tmp/testing. Aside: This is just a courtesy on behalf of rm. It looks at the file and says, hmm, you're allowed to delete it, but maybe you made it read-only because you want it to stay there... that's worth querying the user. That's why this one is slightly different from the other examples. ChrisA -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/captjjmrmexldx-5_ah5hmsjdon5votdo5gajwcbgxcqembo...@mail.gmail.com
