Hi Isaac,
As Shadi suggested, you can probably work around the KDE startup problem by
logging in as root and then doing su (or sudo) to change to another user to
run Wine.
That will most likely get you up and running, and is worth trying in order
to test things, but it is still a significant security risk, and if you
want to run your system any length of time, you probably want to fix this.
KDE does not need to be superuser to run, and if you are having permission
problems, there is probably a glitch in your installation. I haven't
messed with KDE for a long time, but it probably has log files somewhere
that might give you a clue as to what is going on.
My first suspicion is that if you have been doing as you said and logging
in as a normal user and then doing an "su" before starting X, KDE, or Wine,
you may have root-owned files in your home directory. (If you do "su", you
end up with a root process in the current directory. If instead you use
the flag to login "su -" you end up with a root shell in root's home
directory.) Assuming you did "su", the home directory didn't change and
you probably have root owned log files or stuff that KDE can't open unless
you run it as root and which are just where KDE wants to put the normal
user log files.
In general, nothing under your normal user home directory should be owned
by any other user. You can use the find command to look for offending
files like this: (assuming your normal username is "irabicoff".)
$ cd ~irabicoff
$ find . \! -user irabicoff -print | xargs ls -ld
This will traverse your entire home directory and provide a long listing of
all the files and directory nodes that are not owned by the irabicoff
account.
Unless there is something very peculiar going on, you should be able to do
a "chown irabicoff FILE" to fix this. (You may have to also use a "chgrp"
command if the group ownerships aren't correct.) I don't recommend using
the "-R" flag until you have a sense of what it will change.
Note: this is a repair operation, and you will need to be superuser in
order to do the chown/chgrp commands. You should not need to be superuser
to look for the problem files, and the least privileges principle would
suggest you use "sudo" instead of "su" for the changes. Specifically,
instead of using "su" to get a root shell, you can as a normal user do
"sudo chown irabicoff FILE" and only have root authority for the one
command. (You may need to install or configure sudo if it isn't standard
in your distribution.)
If the KDE hang was caused by a permission problem on the user log file,
this should fix it.
If the KDE hang is caused by something else, you should be able to look at
the KDE log file to find out more details.
Best Wishes,
--Tom
Isaac Rabicoff writes:
> Tom,
>
> I truly appreciate your comprehensive explanation, only a fraction of
> which I was already aware. I have been convinced to not use superuser
> to login. However, when I started up kde as a user (after adding the
> 'echo "exec startkde" > ~/.xinitrc' command), it just hanged on the
> splash screen as it was trying to load peripherals. I believe this is
> because I'm unable to access everything that I installed as root, and
> I'm not sure how I would gain access to this.
>
> I realize this isn't directly a wine-related problem, but it will be
> necessary for me to overcome this before I can attempt to run wine
> without logging in as root.
>
> Thanks,
> Isaac (I'll stick with my real name ;) )
>
> Tom Cavin wrote:
>
> >Hi Ray (aka Isaac),
> >
> >The only programs you should ever run as superuser are those that were
> >designed to be run by superuser and then only under the conditions for
> >which the program was designed. And even that is questionable practice.
> >
> >As a general rule, if a user ever has to do anything as root, something is
> >wrong.
> >
> >Yes, this is a "security precaution", but your use of the word "only"
> >indicates to me that you might have a limited view of security.
> >
> >It isn't just Wine that you shouldn't run as root or superuser, it's any
> >program. On any Unix or Linux computer system, a process running with root
> >(uid=0), (or in MS-Windows a process running with administrator
> >privileges) has unquestioned authority to change the system.
> >
> >Execution privileges directly affect program functionality, and giving a
> >program too many privileges means you may be giving it more than it was
> >designed for.
> >
> >The operating system doesn't care if the command to format the system disk
> >came from a command line of a logged in sys-admin who is wiping the disk
> >before disposal, or from an email virus automatically executed by Outlook
> >Express. If the process issuing the format command has sufficient
> >privileges to wipe the disk ... it's history.
> >
> >That's an extreme example, but there are many lesser issues that can cause
> >more subtle damage. Programs that are designed to be run by
> >non-privileged users may normally probe parts of the file system in order
> >to find a place to store temporary files. This probe can be as simple as
> >checking for read permissions, and a failed check causes the program to
> >look elsewhere for temporary file space. A user program may try to store
> >information in the current directory, and if it can't write there it will
> >switch to a user's home directory. If you run such a program as superuser,
> >the permissions check always succeeds, so you may end up writing files
> >anywhere on your system.
> >
> >in the case of Wine, this is a particularly serious issue. Wine is
> >designed to run programs that were written for a different OS. Regardless
> >of anyone's opinion of the innate reliability of such code, running _any_
> >program in Wine is running it in a foreign environment that has different
> >rules than the program expects.
> >
> >As an analogy, consider average drivers in their home country. They
> >generally follow the rules of the road and know which side of the road to
> >drive on. If you take those drivers to another country where the rules are
> >different, but you keep them on a restricted test track with no other
> >drivers, things can work reasonably well. If you put those same drivers in
> >police cars with the sirens on and the lights flashing, in the middle of a
> >densely populated foreign city where they don't know the language or the
> >rules of the road, you are likely to have problems. If you replace those
> >foreign human drivers with robots hard-coded to drive on the "wrong" side
> >of the street, the odds get even worse.
> >
> >In my mind, that analogy is very close to what you do when you run Wine as
> >superuser.
> >
> >There is one difference though. If you do this on your own machine you are
> >only likely to hurt yourself. It might be interesting to see what happens,
> >and it could even be a good learning experience.
> >
> >But please don't do this on any system you (or anyone else) depends on.
> >
> >Best Wishes,
> >
> > --Tom
> >
> >Isaac Rabicoff writes:
> > > Usurp,
> > >
> > > I appreciate your response. If possible, however, I would like for you to
> > > go into greater detail as to why I shouldn't run wine as root. Actually, I
> > > always login as a user, then upgrade to super user (I realize this is
> > > effectively the same as root). To my understanding, not running programs as
> > > root is only a security precaution and shouldn't affect program
> > > functionality. Am I wrong?
> > >
> > > Thanks,
> > > - Ray (aka Isaac)
> > >
> > > ----- Original Message -----
> > > From: "Sylvain Petreolle" <spetreolle@xxxxxxxx>
> > > To: <wine-users@xxxxxxxxxx>
> > > Sent: Wednesday, July 13, 2005 10:10 AM
> > > Subject: RE: WinNY and Wine
> > >
> > >
> > > > Rule #1: dont run wine as root.
> > > > --- Isaac Rabicoff <irabicoff@xxxxxxxxx> a écrit :
> > > >
> > > > > Hello everyone,
> > > > >
> > > > > I'm trying to figure out how to run Winny2b71 with wine-20050111-r1
> > > > > on 2005.0 Gentoo Linux with kernel 2.6.11 r11 (I thought the version
> > > > > info might be helpful). The result is nothing-- no error message,
> > > > > nothing loads, nothing flashes. I have the program installed in
> > > > > /root/.wine/Apps/Winny2, and I use the appropriate ' wine "[path]" '
> > > > > command to execute the program.
> > > >
> > > >
> > > > Kind regards,
> > > >
> > > > Usurp (aka Sylvain Petreolle)
> > > >
> > > > humans are like computers,
> > > > yesterday the BIOS was all
> > > > - today its just a word
> > > > _______________________________________________
> > > > wine-users mailing list
> > > > wine-users@xxxxxxxxxx
> > > > http://www.winehq.org/mailman/listinfo/wine-users
> > >
> > > _______________________________________________
> > > wine-users mailing list
> > > wine-users@xxxxxxxxxx
> > > http://www.winehq.org/mailman/listinfo/wine-users
> >
> >_______________________________________________
> >wine-users mailing list
> >wine-users@xxxxxxxxxx
> >http://www.winehq.org/mailman/listinfo/wine-users
> >
> >
> >
>
> _______________________________________________
> wine-users mailing list
> wine-users@xxxxxxxxxx
> http://www.winehq.org/mailman/listinfo/wine-users
_______________________________________________
wine-users mailing list
wine-users@xxxxxxxxxx
http://www.winehq.org/mailman/listinfo/wine-users
