Right - Riddle me this. Personally, I don't like the 'nojoilet' option on my cd drive, as IIRC Joilet is/was kinda vaguely relevant to cds or dvds. The 'map=n' seems to be telling disk mapping tools not to bother with this one, which is harmless. I don't know why the blocksize is specified. I'm slightly peeved that something in the system is overwriting my mount options.

So, what's the deal? I'm on Slackware64-Current with XFCE if it matters.

How are you mounting it, with "mount /dev/sr0" or through some GUI front end through udisks2?

I'm with you on not wanting mount options overridden. I don't see anything in your fstab line that would cause those things, the "comment=x-gvfs-show" is so it will show up in gnome'ish file managers (Thunar?) I think.

Joliet (you have a spelling error there) are the Windows extensions on the standard ISO=9660 filesystem CDrom's are normally created with (just like rre (=RockRidgeExtensions) are the *nix ones). The mount option probably is telling you that it detected NO Joliet extensions on this CDrom you've got mounted.
So if this was not a special MS-Windows CD I wouldn't worry about it.

PS: ISO-9660 has uppercase filenames only, Joliet supports mixed case filenames but case INsensative access and rre - of course - is case sensative in its filename handling.
Among other differences, of course.
A CD can support both Joliet as well as rre at the same time, they're a sort of mapping on top of the iso9660 filesystem.
From "man makeisofs"HFS is the CD filesystem used by Apple computers, UDF (Universal Disk Format) is a newer FS for optical (etc.) media that was meant to replace ISO-9660, especially on DVD's.
It didn't really take off, though.

1 members found this post helpful.

@TheRealGrogan: Thx, I am mounting it with mount '/dev/sr0' or 'mount /mnt/cdrom.' I'm pretty sure the 'comment=' option was added by something, because I hardly put it there. Conceivably, I might have pasted those options in. Anyhow, I do have Thunar.

@ehartman: Thanks for the reply. If I'm following your point, you're saying Joilet=RRE to all intents and purposes for the user. I'm not aware of option changing behaviour in the mount command, which is a console command. In your honour, I logged out of X and back to level 3 consoles, and the behaviour was identical. So I'm thinking it is udev or something buried and inscrutable like that. I'm running on SysVinit, so I can't even blame systemd, which seems to have a knack of screwing up everything. Even more irritating is that the particular mount options aren't correct. It's being mounted with 'ro,relatime.' Now IIRC, relatime updates the atime every 15 seconds, but ro prevents any atime updates :-/. So it should be 'noatime.'

Here is the proper way to deal with optical media:

1. Remove or comment out corresponding line(s) in /etc/fstab
2. When needed, type as root:
   Code:

   mount /dev/sr0 /your/preferred/mount/point

I added a line exactly like yours to fstab, and typed "mount /dev/sr0" as my user and got the same anally injected options in my mtab file. This is the default behaviour of the mount program when the user parameter is used. I normally would manually mount mine, as I so rarely read optical media.

If I mount it as root with "mount -t iso9660 /dev/sr0 /mnt/cdrom" I get:

I don't care about those detected options like nojoliet and blocksize, but if I wanted to mount a disc as my user, I sure as Hell wouldn't want things like noexec (think game disc). I guess you could add exec as an option in the fstab line. I doubt you'd mount a /dev directory or want to run SUID binaries from optical media, but you could be explicit about those too.

If I add this to fstab:

I get this in mtab, when typing "mount /dev/sr0" as my user:

Thanks.

It appears whatever I write in /etc/fstab is read by mount, if no further. The effect of removing the "comment=x-gvfs-show" is not to show the desktop icon for the cd, which imho is an improvement. Things do execute - install disks, and wine can run stuff, so noexec and nosuid are apparently ignored.

From the man page: |So I now have It also appears /proc/mounts is the canonical one and modern /etc/mtab should be a symlink to that :-/. Why beats me.
Anyhow, That I can live with. nojoilet,map=n are ok; check=s is a filename sanity check; blocksize - who cares. So this is solved. Mount WAS doing it.

As a CDrom is always ReadOnly the noatime makes no sense as we cannot write to it anyway
(burning a cdr disk goes a wholly different way, not through a mount, you do that to UNmounted media because only afterwards there will be a filesystem TO mount).
And any user can now take over your system by supplying and mounting a prepared CD with suid programs, so to become root ON your system.
There is a reason why the user (=ANY user can mount this) automatically sets noexec,nosuid,nodev !!

My normal mount options for a CD or DVD are
(look up the difference between the "user" and "users" options).

Because I do not trust 3rd party CDroms, they may contain virii or other malware.

Agreed. As the cdrom is ro, any atime setting makes no sense. But the thing was mounting with the relatime option. So, in case it was trying every 15 seconds, I mounted it noatime.

As for any user mounting things suid root, The security of this laptop lies chiefly in it's location. It doesn't move from my study. In fact, being disabled, I don't move that much. Most of my fussiness about security goes into not getting hacked online. If I was taking the laptop around, I'd review security, sure. But I only have one arm working.

There's only one user 99% of the time - me. The other 1% is root. I did install a second user for a media event in 2015, 6 weeks before I had a stroke. The media event was repeated over a weekend in 7 languages(!). It was just as well I did the setup because the people who needed to reconfigure their pcs in advance didn't or couldn't, and had to use mine. So I gave them a set of commands to use presuming they knew nothing about linux and they struggled through. I spent time figuring how to do the various bits for everybody, and it was just as well...

The difference between user, & users in fstab AFAICT, is this. With users, user B can unmount what user A has mounted. I have taken out the 'suid' option allowing 'nosuid', because I take the point about security. Root can mount if root needs to do stuff.

And in my case: if I mounted something "as root" I do not have to use a 2nd su or sudo to UNmount it again. I've set up all of my USB sticks and external hard disks the same way, I dislike having to use root when it isn't necessary.

And about suid (and dev), it's also about this friend that brings a too-cool CD with this new game and you mount it to look at it, but unknown to you (and maybe even him) there's malware on it too. Without the suid option it cannot do too much harm and without exec not at all (the game is run through wine or steam anyway, so doesn't need exec rights).
Even shell-scripts ON a CD can still be executed through "sh /path/script" or even explicitly in bash, but now you KNOW what you're executing (and probably had a look at the code first).
I never knew why you would have device files on a CDrom, so nodev always make sense.

If you use CD's for backup, you should have those backups in (compressed) tar files or so anyway, you cannot make real backups on an iso9660 fs, it is missing too much that a real backup could contain, even with rre enabled.

I once had a case a user group I belonged to distributed a CD with nice (Windows, Delphi) software which had a Word-format documentation (.doc) file ON it, which turned out to contain a macro virus. We had to REdistribute (and recreate, they were not CDr's but real created by a company for us Cdrom disks) the whole thing and replace the contaminated ones). OK, in this case the mount options wouldn't have helped (but setting up your Office suite to NOT automatic execute macro's would).

As ehartman points out the noexec option really just suppresses the exec permission bit on files. It does NOT prevent code on media from being executed; only from being executed directly. That is a shell script with the exec bit set true, what normally happens is the system checks the first line for the #! ... to find out what interpreter is needed and executes that on the script.

Without the exec bit or with noexec mount option in place you can absolutely still manually pass such a script as an argument to an interpreter that *is* executable ie: sh /mnt/cdrom/myscript.sh will work fine.. The same holds for wine, wine /mnt/cdrom/setup.exe will work for the same reason.

The attack you are mostly trying to prevent with this looks like the following:
I create a CD with some files on it. One of those files is named something like 'ls' and its either a binary or script that does something of the attackers choosing.

Next you put the disk in, mount it and change to /mnt/cdrom; of course the first thing you are curious about is what files are on the disk so you type 'ls' and BOOM I have code execution with at least your permissions. That is bad of course because I at least have access to home directory so I can encrypt all the files you actually care about and demand some bitcoins in exchange for the key.

Or uses the default (current) shell if no such line is present

The noexec mount option will prevent that ls from executing, indeed, so you protect yourself against that.
If I really want to execute binaries ON a CDrom, I'll remount it with the exec option added, like
but then I know what I'm doing....

Interesting.

@ehartman: Take your point about nodev, and it's gone into /etc/fstab, thx. I'm not using cds/dvds for backups, I have a 500G usb drive for that.

@chemfire: I thought that whereas Dos and maybe windows started the program search path with the current directory, linux doesn't unless I have './' in the $PATH variable. So in the case you mention (cd to /mnt/cdrom & type 'ls') the ls script would not be run. It's a standard newbie error to be able to see a file not in the $PATH, but not realising you can't just cd there and run it. I don't have './' in the $PATH. That would be brave indeed…

Then the syntax is wrong outside of that: it's 'ls /mnt/cdrom' to ls the files, whereas you want '/mnt/cdrom/ls'

The other thing here of course that 100% of the malware I have actually been handed presumes I'm running windows… which I'm not