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@xxxxxxx >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,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@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
