On Mon, Aug 24, 2009 at 12:55, Richard Elling<richard.ell...@gmail.com> wrote: >> Alice$ cd ~/proj1; ln -s /etc ., >> >> Alice$ echo "Hi helpdesk, Bob is on vacation and he has a bunch of >> files in my home directory for a project that we are working on >> together. Unfortunately, his umask was messed up and I can't modify >> the files in ~alice/proj1. Can you do a 'chmod -fR a+rw >> /home/alice/proj1' for me? Thanks!" | mailx -s "permissions fix" > > Yeah, but that is just a social engineering attack. > If you change chmod, you can just change the suggested > command, and achieve similar results. That's not the point. There is indeed some social engineering at work here, getting the admin to run chmod, but the point is the directory /home/alice/proj1 looks innocent until one examines the contents. So unless the helpdesk notices the symlink to /etc/shadow somewhere in that directory tree, the request contains no hint of malicious intent.
>> Helpdesk$ pfexec chmod -fR a+rw /home/alice/proj1 >> >> Alice$ rm /etc/shadow >> Alice$ cp myshadow /etc >> Alice$ su - >> root# One could achieve the same result with a request to chmod a+rw /etc/shadow, but this would be more noticeable. One of my friends ran into this problem while trying to set an ACL on his data files: chmod followed symlinks that he had created to his home directory and config files in /etc, and broke his whole install. I agree chmod should not follow symlinks. Will _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
