How to disable a USB memory stick per user basis ?
Linux - HardwareThis forum is for Hardware issues.
Having trouble installing a piece of hardware? Want to know if that peripheral is compatible with Linux?
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
Just wondering, why you don't like my solution? Because every user can mount it? There is plenty of hardware present in a computer not accessible for certain users, USB stick is no different. The main condition is satisfied - they cannot use it.
Just wondering, why you don't like my solution? Because every user can mount it? There is plenty of hardware present in a computer not accessible for certain users, USB stick is no different. The main condition is satisfied - they cannot use it.
Hi Emerson,
Thanks for your suggestion, and I'm sorry if I don't understand you, but your suggestion is to mount the device with restrictive permissions in fstab, right ?
I didn't like it because it does not cover all devices and it is no practical to list every device node in fstab.
Sure it works for the device /dev/sde, but what if while the first device is plugged in the system I plug another one ? let say it gets /dev/sdf and it gets mounted with regular permissions !
Theses computers have 8 usb ports (6 unused). If I plug a usb hub with another 8 ports (like that one from dlink) ? There are a large space to cover with this method.
I realize I need to take care not only with usb memory sticks, but with cell phones that have a embbed flash memory and cameras, and multi-card readers too ! They are all USB mass storage devices but with different devices names schemes.
Not really. You determine in your custom rule which device is created with plugdev group. All other plugin devices get root:root or root:disk by default and are not user-mountable. There is no need to put them into fstab.
... All other plugin devices get root:root or root:disk by default and are not user-mountable
Except they are automatically mounted by a root process in background.
We are thinking to use a distro like fedora or openSuSE, and on those distros they make this automatically even the device is root:root by default, and even so it is user accessible.
Code:
[miguel@babylon5 ~]$ mount | grep sdc
/dev/sdc1 on /media/disk512 type vfat (rw,nosuid,nodev,uhelper=hal,shortname=lower,uid=500)
[miguel@babylon5 ~]$ ll -d /dev/sdc1 /media/disk512
drwxr-xr-x 6 miguel root 16K 1969-12-31 21:00 /media/disk512
brw-r----- 1 root root 8, 33 2008-02-28 13:05 /dev/sdc1
[miguel@babylon5 ~]$
the document does imply that all rules found in /etc/udev/rules.d are evaluated, not just the first which applies; therefore it may well be possible that the rules your distribution uses as default will still apply even after you have set your own rule, so that you may give the device to a specific group, but a later rule gives it to everybody else (or the users group or whatever), too.
Robin
The last_rule option is intended to stop this from happening.
Well, general UNIX ideology is to forbid everything and allow access only those blessed to have rights on some particular device. I'm not familiar with HAL, but obviously it is the culprit here, where it gets those mount options? Or, maybe another udev rule can deny creating those devices in whole. Sorry, have to go now.
Would be nice, but looks like the only two ways to run a external program are with the PROGRAM statment that returns a name/string to create the device node and RUN+= directive that could do anything after the device is settle and mounted.
There are no conditional tests on this logic....
Using the RUN+= statement I was able to unmount the device after it was mounted, but there are a small window were the user could use the device. Using the jargon, it is a race condition, and I don't like this approach.
I am thinking to post a question at udev developers list to get some insights.
Well, then, what you do is this. You create a rule that simply runs a program when the device is detected, and nothing else. Let the external program handle mounting.
I have a usb stick that wasn't recognized by udev (a PNY device) and wasn't automatically mounted. I fixed it by creating my own udev rule like this:
#!bin/bash
if [ "$ACTION" == "add" ]; then
mkdir /media/"$2"
mount -t vfat -o rw,user,auto,umask=0 /dev/"$1" /media/"$2"
chmod 777 /media/"$2"
else
umount /media/"$2"
rmdir /media/"$2"
This works fine, with one problem. This mount puts the mount entry in /etc/mtab rather than in /media/.hal-mtab. As a consequence, when I select the "safely remove" option from the kde desktop icon for the stick, it doesn't work since it properly informs me that udev didn't mount the device.
I never bothered to fix it, but the consequence is that I have to manually pop open a shell window and umount the device before removing it if I have written to it.
This doesn't bother me which is why I haven't fixed it, but you would need to fix it, I think, which would require your script to fix up both /etc/mtab and /media/.hal-mtab to make it look like udev did the mount. I don't see this as being a big problem; I just haven't bothered.
<!-- You can change this to a more suitable user, or make per-group -->
<policy user="0">
<allow send_interface="org.freedesktop.Hal.Device.SystemPowerManagement"/>
<allow send_interface="org.freedesktop.Hal.Device.VideoAdapterPM"/>
<allow send_interface="org.freedesktop.Hal.Device.LaptopPanel"/>
<allow send_interface="org.freedesktop.Hal.Device.Volume"/>
<allow send_interface="org.freedesktop.Hal.Device.Volume.Crypto"/>
</policy>
Scroll down, you'll see HAL gets mount options from current desktop!!! I'd say it's sick. At least you know where to dig. You need to force UNIX policy - default denied - or you will get lost in this entire thing.
I think the solution through gconftool-2 is the best.
It is simple, it is clean, it is configurable by user, it is easyly reversed even on the fly, it can be implemented as a entry in /etc/profile or whatever.
It does not work for KDE environment thought. Not a big deal.
To mount the device in read-only mode:
gconftool-2 --type list --list-type=string --set /system/storage/default_options/vfat/mount_options "[ro]"
To mount the device without any permission for the user at all:
gconftool-2 --type list --list-type=string --set /system/storage/default_options/vfat/mount_options "[umask=7777]"
To not mount, display an error message:
gconftool-2 --type list --list-type=string --set /system/storage/default_options/vfat/mount_options "[makeanerror]"
The only problem is the user can issue a gconftool-2 command and revert to the default by:
gconftool-2 --type list --list-type=string --set /system/storage/default_options/vfat/mount_options "[shortname=lower,uid=]"
I can't count with the ignorance of the user to protect that asset.
No Gnome here ... any particular reason gconftool-2 must be user-executable? Will Gnome function correctly if you change permissions? Is it a script? If yes, what commands are inside? A little altering may be feasible.
I like flogging dead horses...no animal cruelty involved.
you may have missed the key reason why 'persistent' udev is the answer from my last link on page 1.
if you already understood this, forgive me and I slink away like the snake I am.
----------
These rules cause udev to look at the sysfs file serial for both printers and, depending on the value in the file, name the printer either lp_color or lp_plain. This ensures that no matter which device was plugged in first or detected first or whether another USB printer is added to the system, both of the printers have the same persistent name.
No Gnome here ... any particular reason gconftool-2 must be user-executable? Will Gnome function correctly if you change permissions? Is it a script? If yes, what commands are inside? A little altering may be feasible.
It is a elf-binary and it is not installed by default in most of distros.
It is a tool for fine tunning several aspects of gnome desktop.
There is even a gui for it that resembles regedit from microsoft....
And yes, changing the executable permissions for root only looks like the way.
I think for SuSE you would use the policy kit to restrict removable drive access.
Yes. This is the best way to do what we need. It follow standards and the rule of "least privilegies".
Dealing with HAL/udev is not the way. The problem has nothing with the device be detect, a device node be created or permissions for that device.
Is all about the device node to be mounted or not. And HAL is responsabile for it in modern distros like openSuSE or Fedora.
Fedora has PolicyKit too.
What I did:
In file /usr/share/PolicyKit/policy/hal-storage.policy I changed the "allow_active" from "yes" to "no" to not mount the device at all.
Code:
<action id="org.freedesktop.hal.storage.mount-removable">
<description>Mount file systems from removable drives.</description>
<message>System policy prevents mounting removable media</message>
<defaults>
<allow_inactive>no</allow_inactive>
<allow_active>yes</allow_active>
</defaults>
</action>
Other interesting value is "auth_admin". When you insert ANY removable mass storage on the system, a pop-up window "System policy prevents mounting removable media" ask for the root password. If the correct root password is typed, the device is mounted as usual, with the regular user permissions !
Reading about PolicyKit I learned is possible to create another policy to check, for example, if the current user is listed in a kind of white list. If it is, the device can be mounted. Cool isn't ?
Anyway, thanks for all great ideas and links you provided. i learned a lot in theses days.
Hi
I know that this discussion took place long ago, but iwondered whether
you found a solution to exclude particular users from using usb-memory
with the policykit.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
Solved
