SLED 11 SP2
people use to plug their usb drives(ntfs, vfat), and SLED mounts auto mount the disk with rw access.
is there any possibility that only ‘ro’ access will be given to all users(including root) when SLED auto mounts the external USB disks(flash drives etc)
I’m going to start by asking, why do you want to do this? I ask because sometimes people ask how to achieve something which restricts a user’s ability to do something and when someone asks them why they want to do that, their answer reveals some flaw in their plan or that it’s just not really worth the hassle.
I’m fairly sure it’s possible to have a USB flash drive mount read-only for everyone, though I’ve not been able to figure out exactly how as yet. There’s two pieces to the puzzle I think - you need to give the user read-only and you also need to make sure they don’t own the device node or mount point. By default if you plug a USB drive in it gets mounted at /media/something and /media/something is owned by the currently logged in user. So even if you changed the permissions of /media/something to 444 the user owns it so could just use chmod to add write permission for themselves.
Exactly how devices get mounted is a bit tangled and opaque. You plug the device in and udev creates device nodes for it. Then hal creates mount a mount point and sets the ownership and permissions. If you’re running GNOME, those ownerships and permissions are controlled, at least in part by gvfs-hal-volume-monitor.
You can make udev do stuff with the device nodes by adding files in to /lib/udev/rules.d/ For example I’ve put a file in there that looks like this:
[CODE]
SUBSYSTEMS==“usb|firewire”, KERNEL==“sd?*”, GROUP=“cdrom”[/CODE]
You can’t use udev to control the mount point ownership or permissions though. (I tried, when the udev rules are processed the mount point does not yet exist.)
Assuming you’re using GNOME, if you open gconf-editor and look under /system/storage/default_options/vfat you’ll see various options. If you remove the uid= option and change the umask option to umask=222 then plug in a in a USB flash drive formatted as vfat you’ll find the mount point owner is root and permissions on the mountpoint are dr-xr-xr-x So now you have a USB flash drive mounted, the logged in user only does not have write permissions and they don’t own the mount point so they can’t give themselves write permissions. If you enforce those gconf settings as mandatory then you have the scenario you want, albeit only for vfat filesystems. To get around this the user logs in with KDE.
gvfs-hal-volume-monitor is passing options for ownership and permissions to hal. So I think you’d need to figure out how to configure hal to set the desired ownership and permissions independently for all USB drives. You may possibly also need to prevent gvfs-hal-volume-monitor and any KDE equivalent running when people log in, I don’t know. hal rules are in /usr/share/hal/fdi/policy
I will be interested to see if anyone has a solution, if only for the technical interest.
Hi
You should be able to with udev-acl and adding a RUN in the rule, eg;
SUBSYSTEMS=="usb|firewire", KERNEL=="sd?*", MODE="0660", GROUP="cdrom"
RUN+="udev-acl --action=$env{action} --device=$env{DEVNAME}"@sharfuddin you need to look at adding an ‘admin’ type user then use
sudo (and visudo) if your wanting users access to commands since your
wanting ‘root’ to be read-only which I don’t think you will be able to
do, since root can go in and change it…
–
Cheers Malcolm °¿° (Linux Counter #276890)
openSUSE 12.2 (x86_64) Kernel 3.4.6-2.10-desktop
up 23:16, 3 users, load average: 0.22, 0.19, 0.15
CPU Intel i5 CPU M520@2.40GHz | Intel Arrandale GPU
[QUOTE=malcolmlewis;9300]You should be able to with udev-acl and adding a RUN in the rule, eg;
SUBSYSTEMS=="usb|firewire", KERNEL=="sd?*", MODE="0660", GROUP="cdrom"
RUN+="udev-acl --action=$env{action} --device=$env{DEVNAME}"[/QUOTE]
Well I’d figured out (but not mentioned) that I could change the device node permissions with the udev rule but even setting them to 0444 doesn’t prevent the logged in user from writing to the drive. Which I must confess to not understanding. I couldn’t see any ACL on the device nodes either. The only way I could fine to prevent the user writing to the drive was by removing their write permission and owenership from the mount point.
udev-acl sounds interesting, but adding the RUN rule you suggest doesn’t appear to do anything and I can’t find anything on the system called udev-acl anywhere, or anything in the repos which looks like it might provide it.
OK, so thought about this a bit more and it occurred to me that you can remount already mounted volume with extra options. It’s a bit of a hack because it doesn’t mount the devices read-only, just causes them to be remounted read-only within a very short period of being mounted.
linux-pho3:~ # cat /lib/udev/rules.d/99-mine.rules
SUBSYSTEMS=="usb|firewire", KERNEL=="sd?*[0-9]*", ACTION=="add" RUN+="/usr/local/sbin/usb_remount %k"
linux-pho3:~ # cat /usr/local/sbin/usb_remount
#!/bin/bash
if [ -z "$2" ];then
$0 $1 foo &disown
exit
fi
while [ -z "$(grep -e "^/dev/$1 " /etc/mtab)" ] ;do
sleep 0.1
done
/bin/mount -o remount,ro /dev/$1
linux-pho3:~ # ls -l /usr/local/sbin/usb_remount
-rwx------ 1 root root 235 Oct 4 22:30 /usr/local/sbin/usb_remountAfter creating the udev file run
linux-pho3:~ # udevadm control --reload-rulesto ensure udev knows about it.
usb_remount calls itself in the background and exits straight away because otherwise it’ll sit there looking for the device to be mounted and whilst it’s doing that it’s blocking the events which cause the drive to be mounted from actually getting mounted.
The expression in the KERNEL part of the udev rule should, I think, match all partitions on a drive but not the drive itself. I.e. it’ll match /dev/sdc1 /dev/sdc2 but not /dev/sdc
Using sd?* meant there was a copy of the usb_remount constantly running checking to see if /dev/sdc had been mounted, which it never is.
Works for me in very limited testing. Your mileage may vary. No guarantee. 
Would still be interested to know why someone would want to do this.