On Tue, Aug 13, 2013 at 08:44:08PM +0530, Sherin A wrote: > On Tuesday 13 August 2013 05:50 PM, Paul Slootman wrote: > >On Tue 13 Aug 2013, Matthias Schniedermeyer wrote: > >>BUT there is no direct vulnerability in that, only processes after that > >>(like backup/rsync) can make a vulnerability out of it. > >... which is what I already wrote. > So the solutions is to upgrade the kernel to 3.6 in all Operating > systems installations. ? If it is one server , then it was a > solution. Is it possible to add a flag to exclude hard inks of > regular file instead of waiting the OS vendors for updating there > kernel to 3.6
Matthias already pointed out that the changed default behavior in new kernel is meant to help users avoid shooting themselves in the foot, but doesn't implement added security. In particular, it doesn't fix pre-existing hardlinks created by users who can't read the file; indeed, it can't, since there is no place where the "creator" of the hardlink is stored. You need to realize that every normal file is a hardlink. /etc/shadow is a hardlink, as is $HOME/my_shadow. There is no "original" or "more important" link to the file, they are all equal in the eyes of the kernel. Why are your files being restored with different access permissions than the original file? The UID/GID/mode should be restored to the same values as in the backup. A users hardlink of /etc/shadow will be restored as root/root, 00640, same as the hardlink before backup, and (necessarily) the same as the original file (remember, every link points to an inode, which is where the metadata is stored: UID/GID/perms/timestamps). Justin -- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html