On Sun, Nov 20, 2005 at 05:30:39PM +0100, seorge wrote:
Hi,
Since I'm not a developerr and therefore can't take part in any discussion here may I ask you to discuss the bug I reported, because Dustin Navea asked me to join this list. Or if nobody really need my presence here, please let me know and I will unsubscribe.
If you run WINE only as user (not as root) this just cannot happen.
Did you run WINE as root?
I've just tried at it appears to have wiped my MBR logged in as a normal User in wheel group. If this is the problem then I purchsed a new drive because of it last month. Oliver.
Ciao, Marcus
___________________________________________________________ Yahoo! Model Search 2005 - Find the next catwalk superstars - http://uk.news.yahoo.com/hot/model-search/
___________________________________________________________ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com
On Sun, 20 Nov 2005 18:33:53 +0100, Oliver Stieber <oliver_stieber(a)yahoo.co.uk> wrote:
I've just tried at it appears to have wiped my MBR logged in as a normal User in wheel group. If this is the problem then I purchsed a new drive because of it last month. Oliver.
Can I have your old one ? ;) Apart from fixing this ugly bug , it looks like something more precise than "dont run as root" is needed before inviting the click-and-go windows crowd to join the party.
Le dimanche 20 novembre 2005 à 18:57 +0100, wino(a)piments.com a écrit :
On Sun, 20 Nov 2005 18:33:53 +0100, Oliver Stieber <oliver_stieber(a)yahoo.co.uk> wrote:
I've just tried at it appears to have wiped my MBR logged in as a normal User in wheel group. If this is the problem then I purchsed a new drive because of it last month. Oliver.
Can I have your old one ? ;)
Apart from fixing this ugly bug , it looks like something more precise than "dont run as root" is needed before inviting the click-and-go windows crowd to join the party.
brw-rw---- 1 root disk 8, 0 nov 20 17:23 /dev/hda If you are not part of the disk group and you are not running as root, this cannot happen. There might be a bug in Wine, but the most important error is people having incorrect rights set or having too much rights.
--- Jonathan Ernst <jonathan(a)ernstfamily.ch> wrote:
Le dimanche 20 novembre 2005 à 18:57 +0100, wino(a)piments.com a écrit :
On Sun, 20 Nov 2005 18:33:53 +0100, Oliver Stieber <oliver_stieber(a)yahoo.co.uk> wrote:
I've just tried at it appears to have wiped my MBR logged in as a normal User in wheel group. If this is the problem then I purchsed a new drive because of it last month. Oliver.
Can I have your old one ? ;)
Apart from fixing this ugly bug , it looks like something more precise than "dont run as root" is needed before inviting the click-and-go windows crowd to join the party.
brw-rw---- 1 root disk 8, 0 nov 20 17:23 /dev/hda
If you are not part of the disk group and you are not running as root, this cannot happen. There might be a bug in Wine, but the most important error is people having incorrect rights set or having too much rights.
I was part of the disk group when my MBR was overwritten because I'd been doing some work on the drives and don't like sudo. Isn't it still a bug in wine that the MBR was overwritten in the first place, even if I'm in the disks group or running as root?
___________________________________________________________ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com
Le dimanche 20 novembre 2005 à 19:04 +0000, Oliver Stieber a écrit :
--- Jonathan Ernst <jonathan(a)ernstfamily.ch> wrote:
Le dimanche 20 novembre 2005 à 18:57 +0100, wino(a)piments.com a écrit :
On Sun, 20 Nov 2005 18:33:53 +0100, Oliver Stieber <oliver_stieber(a)yahoo.co.uk> wrote:
I've just tried at it appears to have wiped my MBR logged in as a normal User in wheel group. If this is the problem then I purchsed a new drive because of it last month. Oliver.
Can I have your old one ? ;)
Apart from fixing this ugly bug , it looks like something more precise than "dont run as root" is needed before inviting the click-and-go windows crowd to join the party.
brw-rw---- 1 root disk 8, 0 nov 20 17:23 /dev/hda
If you are not part of the disk group and you are not running as root, this cannot happen. There might be a bug in Wine, but the most important error is people having incorrect rights set or having too much rights.
I was part of the disk group when my MBR was overwritten because I'd been doing some work on the drives and don't like sudo. Isn't it still a bug in wine that the MBR was overwritten in the first place, even if I'm in the disks group or running as root?
Yes of course that's a bug in Wine. But what I meant is that the security model of Linux if correctly applied (i.e. people don't have rights to make things they are not supposed to do) would prevent such things to happen.
On Sun, 20 Nov 2005 20:26:07 +0100, Jonathan Ernst <jonathan(a)ernstfamily.ch> wrote:
Le dimanche 20 novembre 2005 à 19:04 +0000, Oliver Stieber a écrit :
--- Jonathan Ernst <jonathan(a)ernstfamily.ch> wrote:
Le dimanche 20 novembre 2005 à 18:57 +0100, wino(a)piments.com a écrit :
On Sun, 20 Nov 2005 18:33:53 +0100, Oliver Stieber <oliver_stieber(a)yahoo.co.uk> wrote:
I've just tried at it appears to have wiped my MBR logged in as a normal User in wheel group. If this is the problem then I purchsed a new drive because of it last month. Oliver.
Can I have your old one ? ;)
Apart from fixing this ugly bug , it looks like something more precise than "dont run as root" is needed before inviting the click-and-go windows crowd to join the party.
brw-rw---- 1 root disk 8, 0 nov 20 17:23 /dev/hda
If you are not part of the disk group and you are not running as root, this cannot happen. There might be a bug in Wine, but the most important error is people having incorrect rights set or having too much rights.
I was part of the disk group when my MBR was overwritten because I'd been doing some work on the drives and don't like sudo. Isn't it still a bug in wine that the MBR was overwritten in the first place, even if I'm in the disks group or running as root?
Yes of course that's a bug in Wine. But what I meant is that the security model of Linux if correctly applied (i.e. people don't have rights to make things they are not supposed to do) would prevent such things to happen.
So is the conclusion that users need to set up a special new user with super restrictive rights to protect the system from bugs in wine?! My confidence in wine has just taken a knock. Up until now I have not seen anything that says a wine user should not have access to any other services. Setting up a tightly restricted user soley to run wine is what I do in any case since I am installing windows software and this often necessitates installing IE and other horrors. Maybe this should become an official recommendation. If it is not sufficient to just "not run wine as root" then this should go down as a documentation bug as well.
Le dimanche 20 novembre 2005 à 21:01 +0100, wino(a)piments.com a écrit :
On Sun, 20 Nov 2005 20:26:07 +0100, Jonathan Ernst <jonathan(a)ernstfamily.ch> wrote:
Le dimanche 20 novembre 2005 à 19:04 +0000, Oliver Stieber a écrit :
--- Jonathan Ernst <jonathan(a)ernstfamily.ch> wrote:
Le dimanche 20 novembre 2005 à 18:57 +0100, wino(a)piments.com a écrit :
On Sun, 20 Nov 2005 18:33:53 +0100, Oliver Stieber <oliver_stieber(a)yahoo.co.uk> wrote:
I've just tried at it appears to have wiped my MBR logged in as a normal User in wheel group. If this is the problem then I purchsed a new drive because of it last month. Oliver.
Can I have your old one ? ;)
Apart from fixing this ugly bug , it looks like something more precise than "dont run as root" is needed before inviting the click-and-go windows crowd to join the party.
brw-rw---- 1 root disk 8, 0 nov 20 17:23 /dev/hda
If you are not part of the disk group and you are not running as root, this cannot happen. There might be a bug in Wine, but the most important error is people having incorrect rights set or having too much rights.
I was part of the disk group when my MBR was overwritten because I'd been doing some work on the drives and don't like sudo. Isn't it still a bug in wine that the MBR was overwritten in the first place, even if I'm in the disks group or running as root?
Yes of course that's a bug in Wine. But what I meant is that the security model of Linux if correctly applied (i.e. people don't have rights to make things they are not supposed to do) would prevent such things to happen.
So is the conclusion that users need to set up a special new user with super restrictive rights to protect the system from bugs in wine?! My confidence in wine has just taken a knock.
Up until now I have not seen anything that says a wine user should not have access to any other services.
Setting up a tightly restricted user soley to run wine is what I do in any case since I am installing windows software and this often necessitates installing IE and other horrors.
Maybe this should become an official recommendation.
If it is not sufficient to just "not run wine as root" then this should go down as a documentation bug as well.
I think I still didn't make myself clear. Yes there is (I guess) a bad bug in Wine. But: giving normal users a right to write to /dev/hd? is very dangerous and should be avoided. Why would a normal user need a write access to /dev/hd? ? Wine can have bugs, any other application could have bugs that made them try to write things to /dev/hd?. You could get some virus or whatever that execute with you user's right and you really don't want it to wipe out your hdd, do you ? Regards, Jonathan
Hello,
I think I still didn't make myself clear. Yes there is (I guess) a bad bug in Wine. But: giving normal users a right to write to /dev/hd? is very dangerous and should be avoided.
Exactly, I second this. For example, in my standard Linux setup, the disks have the following permissions: brw------- 1 root root 3, 0 Nov 13 19:58 /dev/hda brw------- 1 root root 3, 1 Nov 13 19:58 /dev/hda1 brw------- 1 root root 3, 2 Nov 13 19:58 /dev/hda2 brw------- 1 root root 3, 3 Nov 13 19:58 /dev/hda3 brw------- 1 root root 3, 4 Nov 13 19:58 /dev/hda4 brw------- 1 root root 3, 5 Nov 13 19:58 /dev/hda5 brw------- 1 root root 3, 6 Nov 13 19:58 /dev/hda6 brw------- 1 root root 3, 7 Nov 13 19:58 /dev/hda7
Why would a normal user need a write access to /dev/hd? ?
I can imagine just a single exception - when it is a windows partition, used directly by some windows "emulation" software (as vmware can). But AFAIK wine cannot do this, so it's not needed there.
Wine can have bugs, any other application could have bugs that made them try to write things to /dev/hd?. You could get some virus or whatever that execute with you user's right and you really don't want it to wipe out your hdd, do you ?
Even the user can have a bug :-). I'm running and administering UN*X systems from 1989 but I still strictly distinguish between root and user rights. I've found it very VERY useful. However, I'm also voting for finding and solving this wine bug. With regards, Pavel Troller
wino(a)piments.com schrieb:
So is the conclusion that users need to set up a special new user with super restrictive rights to protect the system from bugs in wine?! My confidence in wine has just taken a knock. It's the other way around. This never would have been possible with a normal user account. But if somebody "creates a special user" by extending his rights and putting him into the disks group, he should be aware of the implications. I don't think there is a "documentation bug".
Of course that is _not_ an excuse why wine wants to write to the MBR ;)
In Slackware by default the only group which gives the access to some media devices is the disk group. I can imagine that some other distros use the same way. Of course this is partially the problem of users like - later I've created cdrom, floppy, etc. groups, but forget to remove myself from disc group. But I also think Wine should not touch places like MBR. Very rarely we even need to run some applications as root, so it would be a very bad practice if every of those apps just try to access MBR, when actually no need to do that. ------- Original message ------- From: Peter Beutner <p.beutner(a)gmx.net> To: wino(a)piments.com Subject: Re: Fwd: Re: Fwd: MBR was destroyed Date: Sunday 20 November 2005 23:24
wino(a)piments.com schrieb:
So is the conclusion that users need to set up a special new user with super restrictive rights to protect the system from bugs in wine?! My confidence in wine has just taken a knock.
It's the other way around. This never would have been possible with a normal user account. But if somebody "creates a special user" by extending his rights and putting him into the disks group, he should be aware of the implications. I don't think there is a "documentation bug".
Of course that is _not_ an excuse why wine wants to write to the MBR ;)
* On Sun, 20 Nov 2005, seorge wrote:
As a regular user I've launched winecfg as a regular user, then proceeded to the dist setup. I've tried several options like automatic configuration, manual configuration. Then I've tried to change some drive letters manually. After reboot a "PRESS A KEY TO REBOOT" message appeared instead of a GRUB screen.
It would be very helpfull if you will find minimal winecfg operation, which destroys MBR. * On Sun, 20 Nov 2005 wino(a)piments.com wrote:
You should probably try to reproduce this in a more controlled way to establish that it was wine that removed grub.
Yeah, right. Seorge, may you repeat the process of wiping and restoring lots of times? I guess other devs don't like to risk on this. :-P I think it would usefull to know: - whether MBR is wiped by setting some properties in wincfg or just by retrieving them (to look at for)? - creating what link in ~/.wine/dosdevices dir is fatal to the MBR? Is it sufficient to setup only C: (manually, in a way as you did) for that? You may run dd command to retrieve MBR at every moment, calculate it's checksum and see whether it differs or not. I'd do this way: $ dd if=/dev/hda of=./hdd.mbr bs=512 count=1 | 1+0 records in | 1+0 records out $ dd if=/dev/hdd of=./hdd.mbr bs=512 count=1 | 1+0 records in | 1+0 records out $ md5sum *.mbr | bc92a20f6c2c5795635108b000fa1ec0 hda.mbr | e0474e52eca44ebf9389ef3e263e6936 hdd.mbr $ cat hda.mbr | od -t x1 | head -n 5 | 0000000 eb 48 90 d0 bc 00 7c fb 50 07 50 1f fc be 1b 7c | 0000020 bf 1b 06 50 57 b9 e5 01 f3 a4 cb be be 07 b1 04 | 0000040 38 2c 7c 09 75 15 83 c6 10 e2 f5 cd 18 8b 14 8b | 0000060 ee 83 c6 10 49 74 16 38 2c 74 f6 be 10 07 03 02 | 0000100 ff 00 00 80 20 74 4a 04 00 08 fa ea 50 7c 00 00 $ cat hdd.mbr | od -t x1 | head -n 5 | 0000000 33 c0 8e d0 bc 00 7c fb 50 07 50 1f fc be 1b 7c | 0000020 bf 1b 06 50 57 b9 e5 01 f3 a4 cb be be 07 b1 04 | 0000040 38 2c 7c 09 75 15 83 c6 10 e2 f5 cd 18 8b 14 8b | 0000060 ee 83 c6 10 49 74 16 38 2c 74 f6 be 10 07 4e ac | 0000100 3c 00 74 fa bb 07 00 b4 0e cd 10 eb f2 89 46 25 It would be interesting to see, what stays in MBR after it is overwritten. Maybe try comapare hexadec outputs between themselve: $ diff -u hda.txt hdd.txt * On Sun, 20 Nov 2005, seorge wrote:
Next time I booted with grub-floppy and then restored the MBR with grub-install /dev/hda.
* On Sun, 20 Nov 2005, Andreas Mohr wrote:
Whatever will happen during this discussion (hopefully this problem will get fixed!), you should definitely install a new MBR there and then run a Linux boot CD with something like testdisk or similar (qparted or so?) on it in order to restore a proper partition table in your first HDD sector...
I think Seorge did something like that already before your msg, Andreas. :-P
Yes I know, but when it's happend it didn't seems like I performed some special ations. What we've allready know is that it's happend on Slackware system with the user added to the disk group. I've launched winecfg, tried to setup disks automatically, then I've tried to assign D: letter to /mnt/cdrom point ant It wasn't successfull, because something was allready assigned to D:. I've clicked once to automatic, more options, manual etc. and thats all. Zhen I've added my user to audio group, because Wine wasn't able to access /dev/mixer, and finally I've rebooted my PC and all this ended with boot error. I always keep a floppy with grub-floppy, so I was able to restore my MBR. Yes, and on some of my vfat partitions I've found some dot files created by Wine. ------- Original message ------- From: Saulius Krasuckas <saulius2(a)ar.fi.lt> To: wine-devel(a)winehq.org Subject: Re: MBR was destroyed Date: Monday 21 November 2005 11:34
It would be very helpfull if you will find minimal winecfg operation, which destroys MBR.
* On Mon, 21 Nov 2005, seorge wrote:
What we've allready know is that it's happend on Slackware system with the user added to the disk group. I've launched winecfg, tried to setup disks automatically, then I've tried to assign D: letter to /mnt/cdrom point ant It wasn't successfull, because something was allready assigned to D:. I've clicked once to automatic, more options, manual etc. and thats all. Zhen I've added my user to audio group, because Wine wasn't able to access /dev/mixer, and finally I've rebooted my PC and all this ended with boot error. I always keep a floppy with grub-floppy, so I was able to restore my MBR.
Ok, and can restore ~/.wine dir to previous state (maybe "rm -rf ~/.wine && wineprefixcreate" would help) and reproduce this bug again, please? I'd give you some HDD to backup data, but am afraid I am too far from you.
------- Original message ------- From: Saulius Krasuckas <saulius2(a)ar.fi.lt> To: seorge <seorge(a)gmail.com> Subject: Re: MBR was destroyed Date: Monday 21 November 2005 12:42 > Ok, and can restore ~/.wine dir to previous state (maybe "rm -rf ~/.wine > && wineprefixcreate" would help) and reproduce this bug again, please? I've removed my previous .wine dirrectory, so the only thing I can do is to reproduce everything happend with me yesturday: 1. try to launch some win32 application - this will create .wine 2. try to setup disks and change labels. As I undestand after this experiment I need to send something or at the mailing list from the content of the .wine. Please tell me what it should be. > I'd give you some HDD to backup data, but am afraid I am too far from you. Yes, about 2000 km - too far for HDD. So there is no chance: so let me be a mad researcher. Wish me good luck :)
seorge <seorge(a)gmail.com> writes: >> Ok, and can restore ~/.wine dir to previous state (maybe "rm -rf ~/.wine >> && wineprefixcreate" would help) and reproduce this bug again, please? > I've removed my previous .wine dirrectory, so the only thing I can do is to > reproduce everything happend with me yesturday: > 1. try to launch some win32 application - this will create .wine > 2. try to setup disks and change labels. Yes, changing the label is the most likely culprit. It's supposed to check for a FAT filesystem first, but maybe the detection is broken. -- Alexandre Julliard julliard(a)winehq.org
I was part of the disk group when my MBR was overwritten because I'd been doing some work on the drives and don't like sudo. Isn't it still a bug in wine that the MBR was overwritten in the first place, even if I'm in the disks group or running as root?
If sudo is too much pain (and it must be since I have never really used it), just do $ su - # I guess Oliver got what he had asked for :( Wine bug nothwithstanding ;)
Yes of course that's a bug in Wine. But what I meant is that the security model of Linux if correctly applied (i.e. people don't have rights to make things they are not supposed to do) would prevent such things to happen.
So is the conclusion that users need to set up a special new user with super restrictive rights to protect the system from bugs in wine?! My confidence in wine has just taken a knock.
Nope. I don't think that any decent distribution comes with world-writable raw hard drive devices. Even if "world writable" really means "everyone is in the group that has write rights". My FC4 system (hand upgraded through the ages from RH7, through everything in between) sets the raw hard drive devices with read only for disk group, and no users are in that group anyway. I'm puzzled as to what distribution would have user-writeable raw devices. I'd bet that someone somewhere messed things up for the users that were affected by that problem. The "super restrictive" rights that you're talking about are *default* on every self-respecting distro. It actually takes some work to change them. Cheers, Kuba PS. Just in case: I don't buy the argument that having access to cd burner requires such hacks. Either manually set hdwhatever to be writeable by you, or (on udev systems) change udev device permissions in relevant config files.
On Sun, 20 Nov 2005 19:45:51 +0100, Jonathan Ernst wrote:
If you are not part of the disk group and you are not running as root, this cannot happen. There might be a bug in Wine, but the most important error is people having incorrect rights set or having too much rights.
The most important error is that somehow Wine is blasting peoples master boot records! How can *ANYTHING* be more important than that?! I have no clue how such a bug could have appeared but tracking it down and fixing it must be a priority.
On Sun, 20 Nov 2005 22:30:33 +0100, Mike Hearn <mike(a)plan99.net> wrote:
On Sun, 20 Nov 2005 19:45:51 +0100, Jonathan Ernst wrote:
If you are not part of the disk group and you are not running as root, this cannot happen. There might be a bug in Wine, but the most important error is people having incorrect rights set or having too much rights.
The most important error is that somehow Wine is blasting peoples master boot records! How can *ANYTHING* be more important than that?!
I have no clue how such a bug could have appeared but tracking it down and fixing it must be a priority.
Ah, at last , the voice of reason. Thanks Mike. I read some comment that this happens on hitting autodetect in winecfg. Would not have thought it was too hard to find. I still think the doc needs something in big red letters about groups and permissions. There should probably be some safety checks built in that stop it running as root ,etc. that can only be turned off in a way that proves you know what you are doing. If wine is putting itself forward as a migration aid the first thing your average windows afficionado is going to do come steaming in , click , click ,click ; ignore any messages that come up as they have been trained to do on M$ systems and import a bunch of badly behaved software and acompanying viruses. Next thing we know people will be saying Linux is no more stable that windows.
Yes, it's kill MBR when run it as a regular user.
On Sun, Nov 20, 2005 at 05:30:39PM +0100, seorge wrote:
Hi,
Since I'm not a developerr and therefore can't take part in any discussion here may I ask you to discuss the bug I reported, because Dustin Navea asked me to join this list. Or if nobody really need my presence here, please let me know and I will unsubscribe.
If you run WINE only as user (not as root) this just cannot happen.
Did you run WINE as root?
I've just tried at it appears to have wiped my MBR logged in as a normal User in wheel group.
If this is the problem then I purchsed a new drive because of it last month.
Oliver.
Ciao, Marcus
___________________________________________________________ Yahoo! Model Search 2005 - Find the next catwalk superstars - http://uk.news.yahoo.com/hot/model-search/
___________________________________________________________ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com
On Sun, Nov 20, 2005 at 07:06:29PM +0100, seorge wrote:
Yes, it's kill MBR when run it as a regular user.
Can you paste the result of 'ls -l /dev/hda*' and also the result of 'groups' in a mail ? Lionel -- Lionel Ulmer - http://www.bbrox.org/
--- Lionel Ulmer <lionel.ulmer(a)free.fr> wrote:
On Sun, Nov 20, 2005 at 07:06:29PM +0100, seorge wrote:
Yes, it's kill MBR when run it as a regular user.
Can you paste the result of 'ls -l /dev/hda*' and also the result of 'groups' in a mail ?
brw-rw---- 1 root disk 3, 0 Nov 20 17:02 /dev/hda brw-rw---- 1 root disk 3, 1 Nov 20 17:02 /dev/hda1 brw-rw---- 1 root disk 3, 10 Nov 20 17:02 /dev/hda10 brw-rw---- 1 root disk 3, 11 Nov 20 17:02 /dev/hda11 brw-rw---- 1 root disk 3, 2 Nov 20 17:02 /dev/hda2 brw-rw---- 1 root disk 3, 5 Nov 20 17:02 /dev/hda5 brw-rw---- 1 root disk 3, 6 Nov 20 17:02 /dev/hda6 brw-rw---- 1 root disk 3, 7 Nov 20 17:02 /dev/hda7 brw-rw---- 1 root disk 3, 8 Nov 20 17:02 /dev/hda8 brw-rw---- 1 root disk 3, 9 Nov 20 17:02 /dev/hda9 I've just removed myself from the disks group.
Lionel
-- Lionel Ulmer - http://www.bbrox.org/
___________________________________________________________ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com
bash-3.00$ ls -l /dev/hda* brw-rw---- 1 root disk 3, 0 2005-11-20 20:33 /dev/hda brw-rw---- 1 root disk 3, 1 2005-11-20 20:33 /dev/hda1 brw-rw---- 1 root disk 3, 2 2005-11-20 20:33 /dev/hda2 brw-rw---- 1 root disk 3, 3 2005-11-20 20:33 /dev/hda3 brw-rw---- 1 root disk 3, 4 2005-11-20 20:33 /dev/hda4 brw-rw---- 1 root disk 3, 5 2005-11-20 20:33 /dev/hda5 brw-rw---- 1 root disk 3, 6 2005-11-20 20:33 /dev/hda6 bash-3.00$ bash-3.00$ groups users disk lp floppy audio video cdrom scanner bash-3.00$
Can you paste the result of 'ls -l /dev/hda*' and also the result of 'groups' in a mail ?
Lionel
participants (11)
-
Alexandre Julliard -
Jonathan Ernst -
Kuba Ober -
Lionel Ulmer -
Mike Hearn -
Oliver Stieber -
Pavel Troller -
Peter Beutner -
Saulius Krasuckas -
seorge -
wino＠piments.com