allows mounting of EVMS partitions

[Jerome Haltom]

Binary package hint: nautilus

This bug may in fact be part of HAL.

Nautilus for me lists a volume which I am allowed to mount: 245 MB Volume. Double clicking this icon in Nautilus CORRUPTS MY DATA.

The 245 MB Volume is representative of /dev/sda2, which is in actuality an EVMS volume which is ALREADY MOUNTED as /dev/evms/boot.

This is DANGEROUS.

[Jerome Haltom (wasabi)]

critical because it can cause unintentional data loss

[Jerome Haltom (wasabi)]

Correcting the 59.6GB volume. That's a Windows partition. The only partition with the problem is /dev/evms/boot.

[Jerome Haltom (wasabi)]

Most applications which play with these sort of things do so by making sure the declared size of the file system (which has to be read from the file system) matches the actual size of the device. Otherwise, an explicit EVMS meta-data check at the end of the original file system may be fine.

[Sebastien Bacher (seb128)]

What version of Ubuntu do you use?

[Jerome Haltom (wasabi)]

This is feisty.

On Sun, 2006-12-17 at 17:45 +0000, Sebastien Bacher wrote:
> What version of Ubuntu do you use?
>

[Jerome Haltom (wasabi)]

This is feisty. Mostly up to date.

hal (0.5.8.1-3ubuntu6) feisty; urgency=low
...
  * debian/patches/24_ignored_volumes.patch:
    - Replace the old policy about showing/hiding volumes: Now show all
      volumes, except those which are mounted automatically in /etc/fstab.
    - See https://wiki.ubuntu.com/MountAllLocalFilesystems for details.

 -- Martin Pitt <email address hidden> Thu, 7 Dec 2006 15:59:53 +0100

I suspect that take the blame.

[John Vivirito (gnomefreak)]

is this still a problem with hal version 0.5.8.1-4ubuntu1?

[Jerome Haltom (wasabi)]

Yes. Still a problem.

[Martin Pitt (pitti)]

Can you please do 'lshal > hal.txt' and attach hal.txt here? Maybe EVMS volumes have some properties which we could use to detect the situation.

[Martin Pitt (pitti)]

Also, I never touched EVMS, so hints about how to detect an EVMS volume (without any nonstandard external dependencies) are appreciated. Otherwise I'll teach myself about evms, but it'll take a while.

[Martin Pitt (pitti)]

Still waiting for lshal.

[Daniel Holbach (dholbach)]

As described in the previous comments, your report lacks the information we need to investigate the problem further. We'll close this report for now - please reopen it if you can give us the missing information.

[Jerome Haltom (wasabi)]

Sorry for the lateness of this reply. Email was being improperly filtered.

The drive which should not allow mounting is /dev/sda2. It seems to have no metadata indicating it is an EVMS volume. This is because such metadata is at the end of the partition, so it looks like a non-EVMS drive unless you examine the size.

[Jerome Haltom (wasabi)]

Would somebody else like to take a position on whether this is critical for Feisty? Data corruption by nothing more than a double-click is a bit evil.

I'm unsure if this effects previous distro releases.

[Martin Pitt (pitti)]

In the bug above, the reporter has /dev/sda2 as an EVMS volume which is mounted as /dev/evms/boot. However, hal detects it as normal ext3 'filesystem' volume, so that people will see it in the Computer place and mount it. This is dangerous, though, since that will lead to data corruption.

Full lshal is at http://librarian.launchpad.net/7344710/hal.txt.

Now, hal already detects dm and lvm devices. I'm not familiar at all how evms works, so I don't have an off-hand suggestion how to detect such volumes. Any idea about additional information that I can ask from the original reporter?

Thank you!

[Martin Pitt (pitti)]

Thanks for the lshal output. So we now need to find out a command or another method which reliably detects whether or not a given device is an EVMS component.

[Jerome Haltom (wasabi)]

Well, there is evms_gather_info, which returns a complete overview of the EVMS system state. It shows all EVMS volumes and their children. If a device shows up as a "child", then we should obviously exclude it. It's pretty slow to run though, and I'm not sure if it's appropriate to be run repeatedly on every device detection. Maybe it is, as long as it's watershed.

I'm also unsure how we should handle this case for systems that don't use EVMS. How do we know they don't use EVMS if they don't have EVMS installed? I am worried about the cast of a user inserting a hot plugable device which contains an EVMS volume, but the machine not having any of the EVMS packages installed. Do we want to attempt to mount this device? Would this be non-destructable in all cases? What if the user plugs it in, we auto mount it, and THEN the user installs EVMS after the fact, which then builds the EVMS volume and we mount that TOO? Or would we unmount the first volume once we knew it was a child? Before mounting the parent.

All of these decisions are hard ones to program.

An easy way out would be to put EVMS back into the default install.

I'd vote for that for unrelated reasons. =)

Actually, I'd really like to have that conversation again sometime. =/

[Zeuthen (zeuthen)]

Kay, does libvolume_id recognize EVMS? Either way, that's where the bug is... HAL uses libvolume_id for all file system guessing.

[Kay Sievers (kaysievers)]

It does recognize some LVM metadata, not sure what EVMS is using.
Can you please provide the output of:
  /lib/udev/vol_id --export /dev/sda2

[Martin Pitt (pitti)]

I asked the original submitter for that information.

[Martin Pitt (pitti)]

Can you please copy&paste the output of

  sudo /lib/udev/vol_id --export /dev/sda2

here?

Thank you!

[Launchpad Janitor (janitor)]

[Expired for hal (Ubuntu) because there has been no activity for 60 days.]

[Danny Kukawka (danny-kukawka)]

No new infos since 22 months. Close the bug now.