[Wine]WinNY and Wine (Off topic: KDE and root)
Isaac Rabicoff
irabicoff at kc.rr.com
Thu Jul 14 16:34:56 CDT 2005
Tom and Shadi, I really appreciate your willingness to help me in spite
of my inexperience with Linux. You have helped me expand my fundamental
understanding of linux.
Tom: I received a very large output of files from using the find command
you suggested. All directories were hidden, in the format
"./dirname/filename" or often "./dirname/.filename". There are so many
files, I'm sure it would save time by adding full directories with chown
with -R. However, I'm not exactly sure which directories I would need
to add. The ./sys directory has subdirectories such as /java, which
would probably be a dependency for some of my programs such as firefox,
but would it be safe to add the entire ./sys folder? This might have
been unnecessary, but I emailed you my full output of restricted files
(1.8 mb compressed, 10.3 mb uncompressed) in case this might help you
understand my problem.
Thanks,
Isaac
Tom Cavin wrote:cavin at MIT.EDU
>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 at yahoo.fr>
> > > > To: <wine-users at winehq.org>
> > > > Sent: Wednesday, July 13, 2005 10:10 AM
> > > > Subject: RE: [Wine]WinNY and Wine
> > > >
> > > >
> > > > > Rule #1: dont run wine as root.
> > > > > --- Isaac Rabicoff <irabicoff at kc.rr.com> a écrit :
> > > > >
> > > > > > Hello everyone,BokuNoSekai / # ls -a /home/raymondbeautrix
>. .bashrc .ICEauthority .Xauthority
>.. ._cfg0000_.bash_profile .kde .xsession-errors
>.bash_history ._cfg0000_.bashrc .kde3.4
>.bash_logout .dmrc .mcop
>.bash_profile .fonts.cache-1 .qt
>BokuNoSekai / # find . \! -user irabicoff -print | xargs ls -ld
>find: invalid argument `irabicoff' to `-user'
>drwxr-xr-x 20 root root 680 Jul 3 10:33 .
>BokuNoSekai / # ls -a /root
> .gtk-bookmarks .recently-used
>. .gxine registry
>.. .gxmame .scim
>.advance help simulink
>.anthy .ICEauthority stateflow
>.Azureus .icons suja2524410itaskill.joy
>.bash_history install_matlab .superkaramba
>bin install_matlab.out .sversionrc
>.ccache java sys
>.dc++ .kde Themes
>.DCOPserver_BokuNoSekai__0 .kde3.4 .thumbnails
>.DCOPserver_BokuNoSekai_:0 .kderc .thunderbird
>demos .keep toolbox
>Desktop license.txt update
>etc linuxdcpp .ut2003
>extern .local .VERSION
>Firefox_wallpaper.png .lopster .wine
>.fonts.cache-1 .mailcap X11
>.fonts.conf .matlab .Xauthority
>.fullcircle .mcop .xcompmgrrc
>.gconf .mcoprc .xine
>.gconfd .mime.types .xinitrc
>.gimp-2.2 .mozilla .xmame
>.gnome .mplayer .xmms
>.gnome2 .openoffice .xsession-errors
>.gnome2_private .opera .xsmWoQXsx
>.gnome_private .q3a .xwine
>.gnupg .qt
>BokuNoSekai / #
>
> > > > > >
> > > > > > 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 at winehq.org
> > > > > http://www.winehq.org/mailman/listinfo/wine-users
> > > >
> > > > _______________________________________________
> > > > wine-users mailing list
> > > > wine-users at winehq.org
> > > > http://www.winehq.org/mailman/listinfo/wine-users
> > >
> > >_______________________________________________
> > >wine-users mailing list
> > >wine-users at winehq.org
> > >http://www.winehq.org/mailman/listinfo/wine-users
> > >
> > >
> > >
> >
> > _______________________________________________
> > wine-users mailing list
> > wine-users at winehq.org
> > http://www.winehq.org/mailman/listinfo/wine-users
>
>
>
More information about the wine-users
mailing list