DVDs with restrictive permissions are unreadable for normal user

Bug #10550 reported by Shaya Potter
134
This bug affects 16 people
Affects Status Importance Assigned to Milestone
Linux
Fix Released
Medium
Debian
New
Undecided
Unassigned
util-linux (Baltix)
Fix Released
Undecided
Unassigned
util-linux (Ubuntu)
Invalid
Medium
Unassigned

Bug Description

ever since I upgraded pmount, gnome-volume-manager hasn't been able to deal w/
my DVDs correctly.

it mounts the disc as one one would expect, but it can't launch totem. When I
do it manually. I get this error from totem when I try to "Play Disc"

"Failed to play Audio/Video Disc
 Error opening directory '/media/cdrom0/'
VIDEO_TS': Permission denied."

/media/cdrom0 is
dr--r--r-- 3 4294967295 4294967295 88 2004-09-03 18:58 /media/cdrom0/

it's mounted as
/dev/hdc on /media/cdrom0 type udf (ro,noexec,nosuid,nodev,user=spotter)

and an ls of it shows

spotter@dent:~ $ ls -l /media/cdrom0/
ls: /media/cdrom0/VIDEO_TS: Permission denied

though it works as root

root@dent:/home/spotter # ls -l /media/cdrom0/
total 2
dr--r--r-- 2 4294967295 4294967295 508 2004-09-03 18:58 VIDEO_TS

root@dent:/home/spotter # ls -l /media/cdrom0/VIDEO_TS/
total 3736860
-r--r--r-- 1 4294967295 4294967295 12288 2004-09-03 18:58 VIDEO_TS.BUP
-r--r--r-- 1 4294967295 4294967295 12288 2004-09-03 18:58 VIDEO_TS.IFO
-r--r--r-- 1 4294967295 4294967295 47104 2004-09-03 18:58 VIDEO_TS.VOB
-r--r--r-- 1 4294967295 4294967295 51200 2004-09-03 18:58 VTS_01_0.BUP
-r--r--r-- 1 4294967295 4294967295 51200 2004-09-03 18:58 VTS_01_0.IFO
-r--r--r-- 1 4294967295 4294967295 1073170432 2004-09-03 18:58 VTS_01_1.VOB
-r--r--r-- 1 4294967295 4294967295 1073170432 2004-09-03 18:58 VTS_01_2.VOB
-r--r--r-- 1 4294967295 4294967295 1073170432 2004-09-03 18:58 VTS_01_3.VOB

and totem works as root

Revision history for this message
Shaya Potter (spotter) wrote :

btw, this is a hoary system (as the target milestone says now)

Revision history for this message
Martin Pitt (pitti) wrote :

(In reply to comment #0)
> dr--r--r-- 3 4294967295 4294967295 88 2004-09-03 18:58 /media/cdrom0/

This is indeed a quite "unusual" user and group id. However, I do not believe
that this is actually a pmount fault, I rather think you have a faulty
/etc/fstab entry for this DVD.

Can you please attach your /etc/fstab here? Also, I need the output of the
following commands (executed as normal user):

id spotter
pmount -d /dev/hdc # (or hdb, or whatever your CD-ROM drive is)

Revision history for this message
Shaya Potter (spotter) wrote :

I don't see anything out of the ordinary for my fstab

spotter@dent:~ $ cat /etc/fstab
# /etc/fstab: static file system information.
#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc defaults 0 0
/dev/hda3 / ext3 defaults,errors=remount-ro 0 1
/dev/hda4 none swap sw 0 0
/dev/hdc /media/cdrom0 udf,iso9660 ro,user,noauto 0 0
/dev/fd0 /media/floppy0 auto rw,user,noauto 0 0

spotter@dent:~ $ id spotter
uid=1000(spotter) gid=1000(spotter)
groups=1000(spotter),4(adm),20(dialout),24(cdrom),25(floppy),29(audio),44(video),103(plugdev),107(lpadmin),108(scanner)

without a disc
spotter@dent:~ $ pmount -d /dev/hdc
resolved /dev/hdc to device /dev/hdc
device /dev/hdc handled by fstab, calling mount
mount: No medium found

with a disc (after umounting the automount)
spotter@dent:~ $ pmount -d /dev/hdc
resolved /dev/hdc to device /dev/hdc
device /dev/hdc handled by fstab, calling mount

still teh same for mount results
/dev/hdc on /media/cdrom0 type udf (ro,noexec,nosuid,nodev,user=spotter)
dr--r--r-- 3 4294967295 4294967295 88 2004-09-03 18:58 cdrom0

Revision history for this message
Martin Pitt (pitti) wrote :

Hi!

(In reply to comment #3)
> I don't see anything out of the ordinary for my fstab

Right, it looks normal. Also, pmount behaves exactly like mount in this case, so
the actual error is not within pmount.

> dr--r--r-- 3 4294967295 4294967295 88 2004-09-03 18:58 cdrom0

when mounting a volume, the permissions on the files and directories (including
the mount point itself) are taken from the file system of the mounted device. So
if your DVD really specifies an user id of 4294967295 and such restrictive
rights, there is not much pmount can/should do about it. We cannot just alter
permissions at random, other devices like USB hard drives rely on working
permissions.

This error is specific to the DVD you inserted and everything should work with
other CDs / DVDs. Did you burn this particular DVD on your own?

Revision history for this message
Shaya Potter (spotter) wrote :

well, it was a home video type thing. So I took out my commercial Gattaca DVD
(Region 1) (and I have totem-xine and libdvdcss installed)

it auto launches totem fine. However this shows what's going wrong.

spotter@dent:~ $ mount |grep hdc
/dev/hdc on /media/cdrom0 type udf (ro,noexec,nosuid,nodev,user=spotter)

spotter@dent:~ $ ls -l /media
total 6
lrwxrwxrwx 1 root root 6 2004-11-16 13:44 cdrom -> cdrom0
dr-xr-xr-x 3 4294967295 4294967295 88 1998-05-12 15:38 cdrom0

notice the r-x bits, as opposed to the r-- bits for the previous DVD.

I didn't even know udf/iso9660 had a x bit equivalent. Would it be worthwhile
thing to attempt to force? (i.e. at least directories should always have the
a+x bits set)?

Revision history for this message
Martin Pitt (pitti) wrote :

(In reply to comment #5)
> I didn't even know udf/iso9660 had a x bit equivalent. Would it be worthwhile
> thing to attempt to force? (i.e. at least directories should always have the
> a+x bits set)?

As we just discussed on IRC, we cannot randomly alter file permissions on file
systems that support permissions (like UDF).

I am not sure what we should do with broken DVDs; udf does not seem to support
mount options for forcing permissions, so maybe something like this should be added.

Revision history for this message
Shaya Potter (spotter) wrote :

a short update, my star trek iv - a new hope DVD also has the strange uid/gid
(though right perms, so it works fine)

shaya

Revision history for this message
Matt Zimmerman (mdz) wrote :

"Target milestone" is a way for us to mark the target for when a bug should be
fixed, not where it is present.

Revision history for this message
James Henstridge (jamesh) wrote :

I noticed this too. When I ran "pmount -d /dev/hda", I got the following output:
  resolved /dev/hda to device /dev/hda
  device /dev/hda handled by fstab, calling mount

This results in the following permissions:
  $ ls -l /media/cdrom0
  total 6
  drwxr-xr-x 2 4294967295 4294967295 40 2004-10-06 08:14 AUDIO_TS
  drwx------ 2 4294967295 4294967295 2588 2004-10-07 06:22 VIDEO_TS

The number 4294967295 corresponds to -1 when interpreted as a signed 32-bit
value, so it isn't just a random value.

I looked in /etc/fstab, and sure enough there is an entry for the drive. After
commenting it out in fstab, I get the following output from pmount -d:
  resolved /dev/hda to device /dev/hda
  mount point to be used: /media/hda
  no iocharset given, current locale encoding is ISO-8859-1
  Cleaning lock directory /var/lock/pmount/_dev_hda
  find_sysfs_device: looking for sysfs directory for device 3:0
  find_sysfs_device: checking whether /dev/hda is on /sys/block/fd0 (2:0)
  find_sysfs_device: checking whether /dev/hda is on /sys/block/dm-5 (254:5)
  find_sysfs_device: checking whether /dev/hda is on /sys/block/dm-4 (254:4)
  find_sysfs_device: checking whether /dev/hda is on /sys/block/dm-3 (254:3)
  find_sysfs_device: checking whether /dev/hda is on /sys/block/dm-2 (254:2)
  find_sysfs_device: checking whether /dev/hda is on /sys/block/dm-1 (254:1)
  find_sysfs_device: checking whether /dev/hda is on /sys/block/dm-0 (254:0)
  find_sysfs_device: checking whether /dev/hda is on /sys/block/hda (3:0)
  find_sysfs_device: major device numbers matchfind_sysfs_device: minor device
numbers also match, /dev/hda is a raw device
  device_removable: corresponding block device for /dev/hda is /sys/block/hda
  get_blockdev_attr: value of /sys/block/hda/removable == 1
  policy check passed
  attempting mount: executing '/bin/mount -t udf -o
rw,nosuid,exec,nodev,user,sync,atime,uid=1000,gid=1000,umask=007 /dev/hda
/media/hda'
  mount attempt terminated with status 0

In this case, the disc is readable when mounted. However, totem then complained
that it couldn't find an entry for /dev/hda in the fstab ...

Revision history for this message
Matt Zimmerman (mdz) wrote :

The user-group ownership is not the issue here, but the permissions. I think
it's quite common for DVDs to use (unsigned)-1 as the uid/gid, but the files are
generally world-readable as well.

Revision history for this message
Shaya Potter (spotter) wrote :

the perms for the VIDEO_TS folder that James shows are weird as well. it's just
rwx for the owner, so basically, no one but root will be able to view the video.

James, what dvd gave those perms?

Revision history for this message
Martin Pitt (pitti) wrote :

I retitle and correct the package, since pmount is not actually the culprit. It
behaves exactly as mount would.

James, can you please try to remove /dev/hda from your /etc/fstab, try

  pmount -d /dev/hda

and look what the permissions are after this?

Can everybody please try to add "umask=777" to the options in /etc/fstab and
look whether "mount /cdrom" behaves any better afterwards?

Revision history for this message
James Henstridge (jamesh) wrote :

Shaya: the DVD was the first disc from "The Complete Black Books". The second
disc also has similar weird permissions, but the third looks fine (all
read/execute perms on the directories, read perms on the files).

Martin: the "pmount -d" output is in my previous post. When there is an fstab
entry, I get the following:
  $ ls -l /media/cdrom0
  total 6
  drwxr-xr-x 2 4294967295 4294967295 40 2004-10-06 08:14 AUDIO_TS
  drwx------ 2 4294967295 4294967295 2588 2004-10-07 06:22 VIDEO_TS
  $ grep hda /etc/mtab
  /dev/hda /media/cdrom0 udf ro,noexec,nosuid,nodev,user=james 0 0

If I remove the fstab entry and mount the disc, I get the following:
  $ ls -l /media/hda
  total 6
  drwxr-x--- 2 james james 40 2004-10-06 08:14 AUDIO_TS
  drwx------ 2 james james 2588 2004-10-07 06:22 VIDEO_TS
  $ grep hda /etc/mtab
  /dev/hda /media/hda udf
ro,noexec,nosuid,nodev,sync,uid=1000,gid=1000,umask=007 0 0

(ie. all the -1 user/group ownerships have been converted to the given uid/gid).

If I manually mount with a umask of 0 (I assume you meant that rather than 0777
which would mask out all the permission bits) along with the other mount options
pmount is using, I get the same file permissions as in the first case (but due
to the files being owned by me, I can read them).

Given that the file permissions and ownership come from the disc itself, the
best solution might be an "ignore on-disc permissions" mount flag for UDF
filesystems. I wonder what Windows does with the file permissions on UDF discs?

Revision history for this message
Martin Pitt (pitti) wrote :

Thanks James for your debugging. It seems that using pmount actually helps to
get these DVDs working since it can assign uid and gid parameters dynamically.

Shaya, can you please check whether adding the "umask=0" option in /etc/fstab
does the trick for you as well? If that works, then d-i should just create fstab
entries for CD-ROMs which have this option by default.

Shaya, can you additionally try to remove (or, rather, comment out by prepending
a "#" sign) the CD-ROM entry in your fstab at all? Please insert the DVD
afterwards and look what the permissions are.

Thanks!

Revision history for this message
Shaya Potter (spotter) wrote :

doesn't make a difference for me w/ umask=0 or removing it.

Even in the case of removing it, so I get a /dev/hdc that's owned by
spotter.spotter, but since none of the directories are +x, only root can enter them.

I started a thread on linux-fsdevel about this, but didn't get much of a response.

here's my e-mail and Jamie Lokier's response

----

Shaya Potter wrote:
> in looking at the ecma spec
> (http://www.ecma-international.org/publications/standards/Ecma-167.htm)
> and section 4/14.9 where the file entry record is discussed, it shows
> that the permission scheme sort of mirrors unix (i.e. owner, group,
> other and read/write/execute bits). However, the spec is ambigious
> because when it refers to the execute bit, it doesn't talk about
> directories at all. In normal unix, of course one needs the execute bit
> set, however, its probable other systems dont have such a semantic and
> hence buggy dvd authoring programs on those platforms don't check for
> it.
>
> Would it be useful to have a file system option to specify something
> along the lines "buggy_dvd" which automatically gives all directories a
> 0x111 bump?

If the spec doesn't talk about directory execute permissions at all,
and it looks like that is intended, then shouldn't the 0x111 bump be
done all the time for UDF? More exactly, adding execute permissions
corresponding to whichever read permissions are set.

----

any of you ubuntu guys want to write a simple patch? :)

Revision history for this message
James Henstridge (jamesh) wrote :

From what I can tell, not specifying a umask parameter is the same as umask=0,
so discs like the one I tried will still have problems. It is also conceivable
that some weird DVDs would have no permission bits set at all. It is weird that
the different discs have different weird permissions though -- I'd have expected
there to be one or two pieces of broken DVD mastering software that produced
identical broken permissions.

As far as removing the fstab entry for the drive, the two changes I observed
were that the drive got mounted as /media/hda rather than /media/cdrom0, and
Totem complained that it couldn't find the mount point associated with /dev/hda
in the fstab file.

Revision history for this message
Shaya Potter (spotter) wrote :

people who write windows software, probably just test if the DVD is readable on
windows. Windows probably doesn't care about UDF permission scheme. hence,
DVDs created by those broken pieces of software work.

Revision history for this message
Martin Pitt (pitti) wrote :

(In reply to comment #17)
> people who write windows software, probably just test if the DVD is readable on
> windows. Windows probably doesn't care about UDF permission scheme. hence,
> DVDs created by those broken pieces of software work.

I think it would be wrong to arbitrarily override the permissions on UDF
volumes, they have a purpose. Anyone got a suggestion what we should do about this?

Revision history for this message
Matt Zimmerman (mdz) wrote :

This is an awkward situation indeed. There are two use cases:

- The user has a UNIX-like filesystem on the disc and wants to honor its permissions
- The user just wants to watch a DVD

Perhaps we can assume that if the filesystem contents indicate that it is a
video disc, we should ignore the permissions?

Revision history for this message
James Henstridge (jamesh) wrote :

One thing worth noting is that in the default setup for Ubuntu, file permissions
won't prevent the user from reading data off the disc, since the first user is
added to the "cdrom" group, who has read/write permissions to the block device.
 So file permissions won't provide any real security in this case.

Secondly, if the user has a Windows box available, it will give them full access
to the data. It'd be interesting to know what other operating systems do with
UDF file permissions (eg. MacOS X, BSD, etc).

Revision history for this message
Matt Zimmerman (mdz) wrote :

(In reply to comment #20)
> One thing worth noting is that in the default setup for Ubuntu, file permissions
> won't prevent the user from reading data off the disc, since the first user is
> added to the "cdrom" group, who has read/write permissions to the block device.
> So file permissions won't provide any real security in this case.

Yes, but that isn't the only function of file ownership and permissions. For
example, if the disc contained a system backup, the ownership and permissions
should be exposed so that if the user restores a directory, it is restored
intact. The permissions might also grant read privileges for other users on the
system (not in the cdrom group).

Revision history for this message
Martin Pitt (pitti) wrote :

*** Bug 26622 has been marked as a duplicate of this bug. ***

Revision history for this message
KarlGoetz (kgoetz) wrote :

Hi,
Theres been no responce to this bug for quite a while, so unless it gets some new information in the next few weeks i'll reject it.
Thanks again

Revision history for this message
James Henstridge (jamesh) wrote :

When I get back to .au, I'll give the DVDs I had problems with a shot again.

I am not sure why you would reject this bug after the problem was identified. It is (or at least was) a real problem preventing playback of a number of released DVDs by users other than root.

It should either remain open or be marked fixed (if the problem has been fixed or a suitable alternative has been found).

Revision history for this message
Shaya Potter (spotter) wrote :

the DVD I describe in the original message still acts the same as described in the original message (just rediscovered it as in the process of moving and it turned up while packing so tested it again).

Revision history for this message
Misha Koshelev (misha680) wrote :

Alright I am also having this problem (on edgy) and have just run into this bug report. Here is my question, what would be the harm of adding a execute permissions to any file that has read permissions for the user, group, or other (for example if a node is 400 but is really a directory make it 500?). Or at least have an option to do this... please...

Thanks
Misha

Revision history for this message
Martin Pitt (pitti) wrote :

I say it again: there is *no way* for any userspace program to randomly alter permissions on file systems that support permissions (like ext3 and UDF, unlike VFAT and iso9660). If at all, this needs to be fixed at the kernel level.

Revision history for this message
Zotty (launchpad-schijf) wrote :

FYI: I'm having the same problem using Debian testing, kernel 2.6.21.1 with UDF 2.5 patch. Only difference is that I'm not using DVD, but HD DVD. It's quite annoying, so I'm hoping a solution will be found soon.

Revision history for this message
Alan Pater (alan-pater) wrote :

I have bumped into this as well. DVD's which just play using Ubuntu Dapper fail under Feisty with the permission error. The difference seems to be that the DVD is mounted as iso9660 in Dapper, but the same video DVD is mounted as udf in Feisty.

In Dapper:
> > $ mount
> > /dev/hdb on /media/cdrom0 type iso9660 (ro,noexec,nosuid,nodev,user=chele)
> >
> > $ ls -al /media/cdrom0
> > total 10
> > dr-xr-xr-x 1 root root 2048 2005-11-13 12:05 .
> > drwxr-xr-x 3 root root 4096 2007-05-03 23:05 ..
> > dr-xr-xr-x 1 root root 2048 2005-11-13 12:05 audio_ts
> > dr-xr-xr-x 1 root root 2048 2005-11-13 11:16 video_ts
> >
> > ~$ ls -al /media/cdrom0/video_ts/
> > total 4521922
> > dr-xr-xr-x 1 root root 2048 2005-11-13 11:16 .
> > dr-xr-xr-x 1 root root 2048 2005-11-13 12:05 ..

In Feisty
$ mount
/dev/scd0 on /media/SPEAKINGPARTS type udf (ro,nosuid,nodev,uid=1002)

$ ls -al /media/SPEAKINGPARTS/
total 10
drwxrwxrwx 4 fer 4294967295 136 2005-11-13 20:05 .
drwxr-xr-x 4 root root 4096 2007-06-26 10:44 ..
drwxrwxrwx 2 fer 4294967295 40 2005-11-13 20:05 AUDIO_TS
dr--r--r-- 2 fer 4294967295 1392 2005-11-13 19:16 VIDEO_TS

$ ls -al /media/SPEAKINGPARTS/VIDEO_TS/
total 0
?--------- ? ? ? ? ? /media/SPEAKINGPARTS/VIDEO_TS/.
?--------- ? ? ? ? ? /media/SPEAKINGPARTS/VIDEO_TS/..
?--------- ? ? ? ? ? /media/SPEAKINGPARTS/VIDEO_TS/VIDEO_TS.BUP

How would one force video DVD's to mount as iso9660 in Feisty?

Revision history for this message
Alan Pater (alan-pater) wrote :

MS Windows XP mounts this same SPEAKINGPARTS DVD as File System: CDFS, which is Windows speak for iso96600.

Revision history for this message
j^ (j) wrote :

Mac OS X allows a user with admin rights to disable file permissions on external disks (dvd, cd, usb/firewire hard drive).

this must be possible on ubuntu too, this is one of the most common problems i have with friends right now, they burn a disk on os x, does not work on linux, they plug in a usb drive to copy some files, does not work, need to fiddle with root, this gets really annoying on laptops where that person is the only user. what are they supposed to do, know how to remount a disk ignoring permissions? open documents as root, many do that, sure a bigger problem than having a way to ignore / overwrite file permissions to allow the person currently logged in to read/write to external disk, in most cases they can take the disk smash it at the wall anyway, its an external disk, if a removable drive that is plugged in during a user session should not be used by that user, something else is wrong.

Revision history for this message
Pierre Renié (archlinuxien) wrote :

Yes, permission problems are really annoying on Linux. To avoid this problem, the prehistoric FAT32 must be used, and I don't like that.

To fix this bug, there is an "easier" solution than patching the kernel : creating a virtual file system that enables UID/GID/permissions mapping between the real file system and the file system to be available to the user. That's not too hard with FUSE.

And after, integrate it with pmount to enable a default mapping for the user who mounts the disk.

Example :
I've these files on my removable disk :
drwxr-xr-x 1000 1000 2480 2007-08-25 18:09 work
drwxr-xr-x 1000 1000 232 2007-09-01 15:17 videos
drwxr-xr-x 1000 1000 11 2007-04-13 23:35 music
drwxr-xr-x 1000 1000 4500 2007-09-25 21:12 archives

My UID is 1001. I want to mount it to /media/usbdisk. pmount transparently mounts this file system to /tmp/mapfs/internal-sda1, and mounts a new file system that makes a mapping with the real files on /tmp/mapfs/internal-sda1.
To the user, it that gives this :
drwxr-xr-x 1001 1001 2480 2007-08-25 18:09 /media/usbdisk/work
drwxr-xr-x 1001 1001 232 2007-09-01 15:17 /media/usbdisk/videos
drwxr-xr-x 1001 1001 11 2007-04-13 23:35 /media/usbdisk/music
drwxr-xr-x 1001 1001 4500 2007-09-25 21:12 /media/usbdisk/archives

Revision history for this message
Ric Flomag (ricflomag) wrote :

I own a video DVD with the exact same permissions as the one Shaya Potter's used when if filled this bug report: the video_ts directory does not have any "x" bits set, and all files are owned by user -1.

In Feisty, because of bug #112584, it auto-mounts as iso9660 instead of udf and totem plays it happily.
In Gutsy, as bug #112584 has been partially fixed, it auto-mounts as udf and only root can read the dvd.
(https://bugs.launchpad.net/ubuntu/+bug/112584)

Quick fix: i have put iso9660 before udf in fstab to always mount dvds as iso9660:
/dev/hdc /media/cdrom0 iso9660,udf user,noauto,utf8 0 0
(the "utf8" option is a workaround to another long standing and very annoying bug, https://bugs.launchpad.net/ubuntu/+bug/22623, but does not have any effect here.)

Totem now plays my DVD just fine. Obviously, this is not a good solution for everyone, but as i don't mind mounting my udf data DVDs as iso9660, it does not matter to me.

This bug as been here for a long time now, does anyone has a better solution?

@Pierre Renié : your suggestion would not work in some cases, like mine, because only root can read the files if the directory VIDEO_TS does not have the "x" permission set for anyone.

Revision history for this message
Pierre Renié (archlinuxien) wrote :

@Ric Flomag
In my suggestion, the virtual file system might also implement the umask option.

Revision history for this message
jpp (jp-proux) wrote :

same problem on 7.10, user and group=4294967295 on /media/cdrom0.
I delete udf on /etc/fstab for cdrom device and now every things is OK.

Revision history for this message
Claude Paroz (paroz) wrote :

Hopefully this bug can be addressed soon. I have been confronted with this several times in the past. Especially when in a group of people copying some CDs to their hard disks, and the only one having problems is the guy (me) who boasts about Linux :-(
This is the sort of problems that prevents massive GNU/Linux adoption.
IMHO read-only medias (CD/DVD-ROM) should be made world-readable. It's no use trying to respect FS rights when it suffices to boot with Windows or MacOS to be able to read them.

Revision history for this message
Busby (mobusby) wrote :

I see that his bug was originally posted in 2004. I has been almost 4 years and yet there is still not appropriate fix for this problem.

It all boils down to this: the Ubuntu/Linux developers need to recognize that file permissions on udf discs are not worth protecting. A disc that is unreadable by Joe's linux box does little more than annoy Joe, and give him one more reason to switch to Windows or MacOS. The data is hardly protected. As we have seen here, even simply mounting the disc as iso9660 can allow some level of access to that "protected" data.

The ideal solution to this problem is to, by default, mount this disc using udf and assuming that the owner of each file is the user that mounted the disc (which is probably the case, anyway). This is not a "random" change or disregard of the permissions; it is in fact "systematic." Those users who wish to protect the permissions, the obviously more knowledgeable ones who care about the integrity of the udf metadata, ought to be able to manually remount the disc using the current (more restrictive) udf file system.

Of course this is probably not as simple as editing a line in fstab. Unfortunately, I lack the ability to make this happen. Perhaps someone can tell me how much work I am proposing?

Revision history for this message
Andrew Gee (andrewgee) wrote :

I am also suffering from this problem with a commercial DVD.

Revision history for this message
James Henstridge (jamesh) wrote :

It looks like this bug was reported in Fedora too, but there is no resolution there either:

    https://bugzilla.redhat.com/show_bug.cgi?id=160945

As Martin said earlier in the bug, this probably needs an extra option implemented by the filesystem driver to ignore disc permissions (as they might have useful details for non-movie discs, you don't want to ignore them outright).

Revision history for this message
Dave L (wizkey1) wrote :

I've long dealt with this problem. Anytime I come across a problematic DVD, I've got to pop it open via sudo. Which of course raises all kinds of security issues.

I can definitely see the difficulty this causes for a developer. Ideally you want to preserve the permissions, yet the reality is the vast majority of those DVD's floating around are meant to usable by anyone who plops it in a drive.

I think something along the lines of a permission under the Users and Groups like "Use DVD as Owner" might be an acceptable alternative or perhaps a DVD user group that mounts DVD's as owner might suffice.

Revision history for this message
Valentijn Sessink (valentijn) wrote :

A couple of remarks. AFAIK, UDF is mostly used on DVD's, so our first concern is getting these to play (and I'm deliberately avoiding the terms "getting it to work" because that's what it does now, too, in a weird way, albeit). Then, some users will complain about their memory sticks and other stuff that have "suddenly" wrong permissions, but that's IMHO less important. So it's not "randomly change permissions", it's "play the DVD, then clean up".

However, I found out an anomaly. While UDF rights on a DVD can be wrong and Totem will refuse to play such DVD's when you use "file - play [dvd title]", it *will* play the DVD when you run

totem dvd://

So this is my DVD:

 ls -l /media/SING_FOR_DARFUR_ENG_FESTIVAL/
totaal 4
dr-xr-xr-x 2 valentyn 4294967295 40 2008-08-07 16:07 AUDIO_TS
dr--r--r-- 2 valentyn 4294967295 508 2008-05-07 10:24 VIDEO_TS
stout~$ ls -l /media/SING_FOR_DARFUR_ENG_FESTIVAL/VIDEO_TS/
ls: kan geen toegang krijgen tot /media/SING_FOR_DARFUR_ENG_FESTIVAL/VIDEO_TS/VIDEO_TS.BUP: Toegang geweigerd
ls: kan geen toegang krijgen tot /media/SING_FOR_DARFUR_ENG_FESTIVAL/VIDEO_TS/VIDEO_TS.IFO: Toegang geweigerd
ls: kan geen toegang krijgen tot /media/SING_FOR_DARFUR_ENG_FESTIVAL/VIDEO_TS/VTS_01_0.BUP: Toegang geweigerd
[etcetera]
totaal 0
?????????? ? ? ? ? ? VIDEO_TS.BUP
?????????? ? ? ? ? ? VIDEO_TS.IFO
?????????? ? ? ? ? ? VTS_01_0.BUP
[etcetera]

However, running totem dvd:// *will* play this DVD!

Ahem?

In other news: my Imac suddenly changes permissions when a DVD is concerned - I'm currently re-checking and will post my results shortly.

Revision history for this message
Shang Wu (shangwu) wrote :

@Valentijn Sessink

Can you post your /etc/fstab and the mount command when the DVD is in the machine? Also, what is the permissions that it shows under your mac machine for these files:

?????????? ? ? ? ? ? VIDEO_TS.BUP
?????????? ? ? ? ? ? VIDEO_TS.IFO
?????????? ? ? ? ? ? VTS_01_0.BUP

Revision history for this message
Valentijn Sessink (valentijn) wrote :

Mac OSX seems to recognize that it's a DVD, and change permissions accordingly. I fail to reproduce this behaviour on CD/USB or other storage device. So as far as I can see, there's a special "hey, it's a DVD, let's randomly alter file permissions". So OSX *can* do it; Ubuntu should be able to do it, too, right?

Revision history for this message
Shaya Potter (spotter) wrote : Re: [Bug 10550] Re: DVDs with restrictive permissions are unreadable for normal user

in regards to totem being able to play the DVD, it could possibly be
that totem has a UDF parser within it, and is reading the raw device and
hence ignores the permissions.

In regards to UDF permissions, a possible solution (possibly hack) to
the issue instead of getting rid of permission entirely

1) mount disk on insertion
2) check if it's video DVD (AUDIO_TS/VIDEO_TS folder)
3) check perms
3a) if invalid, remount with option to sanitize perms

Revision history for this message
Helmut A. Bender (ubuntu-helmut-bender) wrote :

This is not inly a concern with video DVDs.

I have a data DVD which I try to install into WINE:

-rw-r----- 1 501 dialout 48 2008-08-29 08:12 autorun.inf
drwx------ 2 501 dialout 492 2008-08-29 08:12 DirectX
-rw-r----- 1 501 dialout 109638 2008-08-29 08:12 disc.ico
-rwx------ 1 501 dialout 1407832 2008-08-29 08:12 Installer.exe
-rwx------ 1 501 dialout 1632129045 2008-08-29 08:02 Installer Tome 2.mpq
-rwx------ 1 501 dialout 2512316598 2008-08-29 08:07 Installer Tome 3.mpq
-rwx------ 1 501 dialout 2329021933 2008-08-29 08:10 Installer Tome 4.mpq
-rwx------ 1 501 dialout 1269323225 2008-08-29 08:11 Installer Tome 5.mpq
-rwx------ 1 501 dialout 155380459 2008-08-29 08:11 Installer Tome.mpq
-rwx------ 1 501 dialout 340621200 2008-08-29 08:12 Movies.mpq

I can't install it as user since the group can't read and no user with this id exists, and I can't install it as root since wine needs to run as user. I can't use iso9660, since there are files over 2GB.

The only thing that would work is to change thw owner or the permissions. Both I can't do.

Revision history for this message
Sam Morris (yrro) wrote :

Whatever screwed up process Adobe used to master the CD for Flash 8 also has this problem. The files are not readable unless the user knows how to remount the CD with the correct magical mount options. What's worse is that Wine simply says "file not found" rather than "access denied" when asked to run the installer, making even the diagnosis of the problem harder than it should be.

Revision history for this message
Constantin Berzan (exit3219) wrote :

I second the fact that this is not a problem with video dvds only. I came across it while trying to install matlab 2008a from the official dvd.

It automatically mounts as udf, but:

$ ll /mnt
ls: cannot access /mnt/InstallForMacOSX.app: Permission denied
ls: cannot access /mnt/inst_doc.pdf: Permission denied
ls: cannot access /mnt/install: Permission denied
ls: cannot access /mnt/license.txt: Permission denied
ls: cannot access /mnt/mac_install_guide.pdf: Permission denied
ls: cannot access /mnt/readme.txt: Permission denied
ls: cannot access /mnt/update: Permission denied
ls: cannot access /mnt/utils: Permission denied
total 0
?????????? ? ? ? ? ? install
?????????? ? ? ? ? ? InstallForMacOSX.app
?????????? ? ? ? ? ? inst_doc.pdf
?????????? ? ? ? ? ? license.txt
?????????? ? ? ? ? ? mac_install_guide.pdf
?????????? ? ? ? ? ? readme.txt
?????????? ? ? ? ? ? update
?????????? ? ? ? ? ? utils

If I force it to mount as iso9660, I lose the long file names. None of the umask,exec,suid options help.

The only way to install it was to copy everything (as root) to the hard drive and manually add +x to the install scripts.

See also:
http://www.walkingrandomly.com/?p=170&cpage=1#comment-9008
http://ubuntuforums.org/showthread.php?t=971386

Martin Pitt (pitti)
Changed in util-linux:
assignee: pitti → nobody
Revision history for this message
Jorge Juan (jjchico) wrote :

Hi,

I have the same problem with broken udf permissions generated by a comercial DVD player/recorder, a Samsung DVD-SH873.

Ubuntu intrepid
Linux ubuntu 2.6.27-11-generic

# ls -l /media
...
d--x--x--- 3 4294967295 4294967295 84 2009-01-31 17:36 cdrom0
...

In my case, there is missing world acces permission and there is missing read permissions at all. Very surprisingly, it only happens in the top (root) directory in the file systems because the contents seems to have right permissions:

# ls -l /media/cdrom0
dr-xr-xr-x 2 4294967295 4294967295 2232 2009-01-31 17:36 MOVIE
...

This is a data DVD with recorded divx files, so it is not a DVD-VIDEO disk, so the problem is not only about DVD-VIDEO.

This particular DVD cannot be mounted as iso9660, so this workaround does not help:

# mount -t iso9660 /dev/scd0 /media/cdrom0/
mount: block device /dev/scd0 is write-protected, mounting read-only
mount: wrong fs type, bad option, bad superblock on /dev/scd0,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail or so

So, none of the proposed solutions would work for me (except being root).

In my opinion, the good solution would be something like this:

1. At kernel driver level, there should be an option to set "effective" file permissions different from what is in the filesystem. When you mount the device, you see the permissions on the filesystem and they are preserved when you copy, etc. as people doing backups like, but you will be able to read and list files based on "effective" permissions that override fs permissions. Simple said, the kernel do not honor fs permissions at read time.

2. At desktop level, you (the user) are able to select related properties to removable media in a place like System->Preferences->Removable media. The system would use the above related facilities to implement that. The options may be:
- Make removable media always readable
  - Apply only to read-only media
- Make files copied from removable media readable

I hope people at Ubuntu/Linux Kernel would implement something like that. Unfortunately, my coding skills are far from being able to do something like that.

Revision history for this message
Jorge Juan (jjchico) wrote :

Today I discover someone already submitted a patch to kernel developers that implements mode and dmode options for udf, which is basically point 1 in my last post. Brave kernel people!

http://lkml.org/lkml/2008/11/16/229

I cannot find it in the changelogs for the latest kernels yet, so I am afraid we will have to wait for 6 to 12 months for it to make it into Ubuntu. I hope some ubuntu developer will use it to make broken udf dvd's readable in Ubuntu in a future release.

Revision history for this message
Phil Turmel (pturmel-lp) wrote :

The mode and dmode options mentioned above by Jorge have been merged in linux 2.6.30-rc as commits:

7ac9bcd5da59dd96eb1153d3fc04c3471fa5c09d
87bc730c07a0884d14d6af5c9d49f4669c0a0589

Revision history for this message
Phil Turmel (pturmel-lp) wrote :

I cherry-picked those two commits into a fresh branch of v2.6.29. They applied cleanly, and appear to work correctly. My fstab line now looks like this:

/dev/cdrom /mnt/cdrom udf,iso9660 noauto,users,uid=0,gid=444,mode=0777,dmode=0777,nosuid,noexec 0 0

This combination will r/w mount any UDF disk that supports it (DVD+RW, DVD-RAM), and intelligently fall back to r/o on either UDF or ISO9660 as needed. Note: gid 444 = plugdev, for use with hal. The appropriate gid for you may vary.

Tested on KDE-3.5.9 w/ hal, using a CD created on windows w/ numerous jpegs, a DVD+RW created by a stand-alone Samsung DVD recorder, a DVD-RW created by the same Samsung recorder (DVD-VR mode), and a DVD+RW created by linux with a writeable UDF filesystem.

Revision history for this message
dcam (david-pastornet) wrote :

This problem also occurs with DVDs created by Panasonic DVD recorders, at least the DMR-EH65.

Revision history for this message
dcam (david-pastornet) wrote :

The UDF ECMA specification at The ECMA spec at http://www.ecma-international.org/publications/standards/Ecma-167.htm defines an execute bit which if set means that the user "may execute the file".

There is absolutely no wording in the spec that to read the contents of directories, that "execute" permission must be provided on directories. Executable directories seem undefined, nonsensical under the spec.

It seems to me that permission 444 directories are legitimate and should be readable under the spec.

Revision history for this message
dcam (david-pastornet) wrote :
Revision history for this message
Phil Turmel (pturmel-lp) wrote :

dcam:

Please read the spec a little closer: "File Entry" as defined in 4/14.9 applies to "File Types" 0, and 4-10. Following the spec back to 4/14.6.6, you discover that file type #4 is a directory, and #5 is a generic file. Types #6 through #10 are other well-understood *nixy items.

In any case, note #27, which immediately follows the permissions description in 4/14.9.5, clearly leaves discretion in the hands of the implementor, even to not implementing these at all. Its hardly surprising that linux implements these permissions as is traditional.

In any case, the new dmode mount option in 2.6.30 (noted above) is a working solution, if you're willing to try an rc kernel. Or apply the patches to 2.6.29.

Revision history for this message
h3 (h3) wrote :

I got the very same problem tonight .. I rented a movie on DVD and as it happens half the time, it didn't work.

Every time it's the same circus;

1. Encounter a permission problem when trying to read a rented DVD in totem or VLC
2. Fire Windows on Virtualbox, try with VLC .. half the time it works, if not ..
3. Search the web, find something about CSS drm bullshit or somthing ..
4. Try to install libCSSwhatever or extras packages and find out it don't work either
5. Remember how I did workaround the last time; open VLC, File -> Open *DIRECTORY* browse for "VIDEO_TS" in the DVD drive, click "open" and watch movie.

I'm still not sure if I should blame Ubuntu for not being able to read a DVD correctly or the movie industry for not being able to write a DVD properly.

Changed in linux:
status: Unknown → Fix Released
Revision history for this message
Busby (mobusby) wrote :

If a fix was released, it certainly hasn't reached by Ubuntu 9.04 machine. I just tried to read a CD burned with a mac, and I could only mount it if I performed the mount as root.

Unfortunately, I am not willing to try an RC kernel, or apply patches to the kernel myself. I am more than willing to install a kernel upgrade from the repository, however. Will the patch mentioned be implemented by the time 9.10 is released?

Revision history for this message
Busby (mobusby) wrote :

Just upgraded to 9.10 Beta and the behavior had definitely changed. Using this line in my /etc/fstab now makes problematic DVDs behave properly.

/dev/scd0 /media/cdrom0 udf,iso9660 users,noauto,uid=0,gid=46,mode=0777,dmode=0777,nosuid,noexec 0 0

The old line (default from Ubuntu install) was

/dev/scd0 /media/cdrom0 udf,iso9660 user,noauto,exec,utf8 0 0

Apparently the patch has been released. Many thanks to all involved.

Revision history for this message
apanloco (apanloco) wrote :

Thanks Busby, your solution did wonders over here on 9.10. (A custom-made family-DVD from Windows gave me issues.)

Revision history for this message
Cyril Jaquier (cyril-jaquier) wrote :

I also had problem today with an UDF cdrom on Karmic.

$ ll /media/cdrom0/
total 1553872
-rw------- 1 501 dialout 1821327 2009-09-06 18:16 IMG_0004.JPG
-rw------- 1 501 dialout 2179273 2009-09-06 18:16 IMG_0005.JPG
-rw------- 1 501 dialout 1996985 2009-09-06 18:20 IMG_0006.JPG
-rw------- 1 501 dialout 2384917 2009-09-06 18:21 IMG_0007.JPG
-rw------- 1 501 dialout 2795108 2009-09-06 18:21 IMG_0008.JPG
-rw------- 1 501 dialout 2357335 2009-09-06 18:21 IMG_0009.JPG
...

The user id 501 is probably the user id of Mac user who burnt the disk. devicekit-disks (or something else) mounted the disk automatically.

Revision history for this message
Michel Meyers (steltek) wrote :

Also have this problem but with an iso9660 mounted disc:

# ls /media/cdrom0/ -l
total 4194307
-rwx------ 1 400 401 29 2006-04-12 08:44 autorun.inf
-rwx------ 1 400 401 31318365 2006-04-12 08:31 data1.cab
-rwx------ 1 400 401 28222 2006-04-12 08:31 data1.hdr
-rwx------ 1 400 401 3913673645 2006-04-12 08:44 data2.cab
-rwx------ 1 400 401 348854339 2006-04-12 08:44 dream00.dat
-rwx------ 1 400 401 543481 2005-04-07 01:39 engine32.cab
-rwx------ 1 400 401 475 2006-04-12 08:44 layout.bin
-rwx------ 1 400 401 121064 2005-04-07 01:39 setup.exe
-rwx------ 1 400 401 382094 2006-04-12 08:31 setup.ibt
-rwx------ 1 400 401 473 2006-04-12 08:31 setup.ini
-rwx------ 1 400 401 44941 2005-04-04 02:50 setup.isn
-rwx------ 1 400 401 168 2006-04-12 08:07 version.txt

Kernel 2.6.30-1-686-bigmem. mask and dmask options don't help (OK, dmask can't work as there is no directory, but mask is ignored as well).

Revision history for this message
Lorenco Trichardt (trichalo) wrote :

I am having a issue on Lucid. Hopefully this bug can be killed at some point. Running "totem dvd://" does the trick. So when are getting a final fix on this ?

Revision history for this message
rusivi2 (rusivi2-deactivatedaccount) wrote :

Thank you for reporting this bug.

Does this occur in Maverick?

Changed in util-linux (Ubuntu):
status: Confirmed → Incomplete
Changed in util-linux (Baltix):
status: New → Incomplete
Changed in debian:
status: New → Incomplete
Revision history for this message
Mantas Kriaučiūnas (mantas) wrote :

rusivi2 wrote on 2010-09-14:
> Does this occur in Maverick?
Yes, updated Ubuntu Lucid and Maverick systems still have problems with some UDF DVD's, this is confirmed by several people, see bug #635499 - there is real workaround described and bug is confirmed by Ubuntu developers!

Revision history for this message
rusivi2 (rusivi2-deactivatedaccount) wrote :

Mantas Kriaučiūnas thank you for reporting your results and helping to make Ubuntu better. Marking Status Confirmed based on your comments.

Changed in util-linux (Ubuntu):
status: Incomplete → Confirmed
Changed in util-linux (Baltix):
status: Incomplete → New
Changed in debian:
status: Incomplete → New
Changed in linux:
importance: Unknown → Medium
Revision history for this message
Ankit Bansal (ankitbansal-nitj) wrote :

Is this problem solved in ubuntu 10.04? or which kernel version is fixing this problem?

Revision history for this message
Thomas Hotz (thotz-deactivatedaccount) wrote :

#66 Is it fixed in Ubuntu 12.04 LTS? Please tell us!

Changed in util-linux (Ubuntu):
status: Confirmed → Incomplete
Changed in util-linux (Baltix):
status: New → Invalid
Changed in util-linux (Baltix):
status: Invalid → New
Changed in util-linux (Ubuntu):
status: Incomplete → Invalid
Revision history for this message
Fifoxtasy (philipp-foerster) wrote :

[quote]
Busby (mobusby) wrote on 2009-10-15: #58

Just upgraded to 9.10 Beta and the behavior had definitely changed. Using this line in my /etc/fstab now makes problematic DVDs behave properly.

/dev/scd0 /media/cdrom0 udf,iso9660 users,noauto,uid=0,gid=46,mode=0777,dmode=0777,nosuid,noexec 0 0

The old line (default from Ubuntu install) was

/dev/scd0 /media/cdrom0 udf,iso9660 user,noauto,exec,utf8 0 0
[/quote]

Thanks Busby for the fstab entry! your configuration solved the problems that i'm having accessing with video dvd. it's a shame that in 2015 i still need to configure this manually to access the content of dvd video.

Revision history for this message
uwe (maabdulhaq) wrote :

yes, i think the problem still exists in 14.04 ; maybe will also in 16.04 ... but the cd/dvd line is not /etc/fstab ; so even that workaround is working...

Revision history for this message
uwe (maabdulhaq) wrote :

Sorry, is *not* working for me ...

Revision history for this message
Phillip Susi (psusi) wrote :

This was fixed a *long* time ago. DVDs are mounted with the correct uid option so that files owned by nobody appear to be owned by the logged in user.

Changed in util-linux (Baltix):
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.