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 into the 't' bit on the /tmp directory. $ ls -ld /tmp drwxrwxrwt 13 root root 500 Jun 5 21:32 /tmp Research why that bit is there. What behavior does it enforce? For extra credit research the limits of chown. On System V any user can chown files they own to other users. On BSD this is not allowed. The Linux kernel follows BSD in this behavior. The Linux kernel does not allow non-root users to chown files to other people. Why not? What problems occur if they are allowed to do so? Why is this related to the 't' bit on /tmp? Hope that helps, Bob
signature.asc
Description: Digital signature
