Red Hat Bugzilla – Bug 130290
fstab-sync makes all entries suid,dev
Last modified: 2007-11-30 17:10:47 EST
Description of problem:
Enter magic floppy/cdrom containing ext2 filesystem and some harmless
[pp@the ~]$ mount /media/floppy/
[pp@the ~]$ cd /media/floppy/
[pp@the floppy]$ ls -l
drwx------ 2 root root 12288 Aug 18 23:29 lost+found
-rwsr-xr-x 1 root root 529492 Aug 18 23:33 sh
[pp@the floppy]$ ./sh
Stand-alone shell (version 3.7)
> touch /0wned
> ls -l /0wned
-rw-rw-r-- 1 root pp 0 Aug 18 23:43 /0wned
Looking at fstab-sync.c there seem to be quite a few alternatives, all
of them containing dev,suid. Not good (tm).
Reasigned to Ray Strode and cc'ed David. This should go upstream.
Hm. This is more or less in line with previous behavior, though.
I'm patching hal right now to take out the suid and dev flags as a
stopgap solution. Should I go ahead with this?
Makes sense, I'll fix it upstream. Thanks.
Well, if you just take out suid/dev, it should revert to the defaults.
Which is 'suid,dev'. :)
They are all added with "user" which implies "nosuid" and "nodev". At
least that is what it says in the mount man page.
Carry on, don't mind me then. :)
Any particular reason you're using 'user' and not 'owner'?
What are the implications for dynamicly added devices? As I
understand it console permissions are only set when a user logs in.
What happens when udev creates a device node after the user has logged
in? Otherwise owner seems like the correct flag to use here.
udev has/had a helper to do this. I suppose I should make sure it's
still there and working.
We don't want to use owner because then we'll need to give permission
to the device node and that gives the user the ability to read or
destroy all data through the device node (if the partition has an ext3
filesystem some files may be unreadable for the user if mounted;
that's a feature).
We do, however, want to get the console user to own the device node
when it represents an optical drive (so he can eject(1) it and burn
discs with to it). That's bug #130094 and bug #130095.
Indeed. In fact, with the current stuff entries for idedisk
and scsidisk were created for partitions which are unmounted
more or less on purpose (in my case an old /boot partition
I don't use for anything, and idedisk is a LVM thingy that isn't
mountable). Plugging in a digital camera (basically a USB card reader,
/dev/sdb) didn't cause an entry to be added at all
I think the stuff should be pretty conservative on what devices
to create fstab entries for by default and if the admin wants
something else then that should be enabled manually.
Right, /boot should probably be blacklisted and fstab-sync shouldn't
add entries for devices with no filesystem on; we have a filesystem
prober in hal, so the properties volumes.fstype and
volume.is_filesystem should be honoured. I'll be fixing all these
issues today in upstream (I'm the upstream maintainer) and hope to
push out a new package tonight.
Btw, care to attach the output of lshal and 'tree /sys' for your
system, just so I can doublecheck everything is set correctly for LVM
systems (I haven't tested on those yet).
Created attachment 102871 [details]
Created attachment 102872 [details]
Thanks, that's very useful.
> Plugging in a digital camera (basically a USB card reader,
> (/dev/sdb) didn't cause an entry to be added at all
That's a bug, this should really work. We even try to look at the main
block device (/dev/sdb) for the odd media that doesn't have partition
tables. Does it hal detect it properly, can you see it in
hal-device-manager? Please attach the relevant /sys and lshal snippets.
Any objections to clearing the "Security Sensitive" flag on this bug
so it can be viewed publically? Pekka?
No problem here, the fixed version got reported on the rawhide report
anyway so the problem is "out" :-)
Camera problem reported as new bug #130355. hal-device-manager sees
the camera just fine.
Are you sure you just want to restrict 'owner' to a optical drive?
Seems flash such as a USB key or camera media may also want this flag.
No no, I'm saying don't use 'owner' at all, always use 'user'. Why
should we use 'owner' at all?
I'm closing this bug as this is fixed both upstream and in Rawhide.