Not at all !

The machines are regular desktop computers with hard drives, sound (internal speaker), and usb keyboard and mouse.

They will run some distro in graphical mode (Fedora/openSuSE and Gnome probably), and a special application that read that big file they don't want to be copied outside of this environment.

Theses computers are in a network, no shares any kind, just to communicate to a database server. At some point, each user may generate a big file for local processing (due to network performance issues). This file is volatile, I mean, the information in this file is good until to the next 4-6 hours. And partial knowledge of this file is not a issue too.

Just the members of board of directors may copy data out of this environment.

The users don't have any administrative previleges.

And thanks for the links for documentation.I will read ASAP.

cheers,

I found udev to be a PITA, and I still find it to be a PITA even though I kind of have the hang of it.

You probably need to write your own rule, patterned off of persistent-storage.rules, but limited to devices on the USB bus and running ahead of that rule in the list.

That would probably be simpler.

I've made some progress, thanks to documentation aus9 pointed to me - Hey aus9 thank you !

What I did:

in the file 60-persistent-storage.rules there are several references to sd devices (KERNEL=="sd*[0-9]").
The first step was to identify which one of theses are "activated" or matched by a usb memory stick. To figure out this, I added at end of each line, the statement ENV{MYFLAG}="flag-<number>", I mean:

And in a console, running "udevmonitor --env | grep -i MYFLAG" I was able to identify several rules that match for each usb memory stick based on number of the flag they show. For instance, the rules with flag-1, flag-3 and flag-4 matched for the a dozen of memory sticks I tried with. (of course, I need to plug and unplug the usb memory stick to trigger the events and see any output of udevmonitor)

Then,in the selected rules, I put at end, another statement: OPTIONS+="ignore_device" which I learned in the documentation.

A rule now, looks like:
And, as result, the usb memory stick is not automatically mounted anymore, as expected.

In fact, this was my second attempt. The first was using the statements OWNER, GROUP and MODE, but looks like they don't worked for me....more investigation is necessary.

Now, what I need to do is to ignore the device or adjust the onwer/group/mode to restrict the access the way they need.

Anyway, looks like I am in the right path.

Thanks for the help !

jiml8 links?

how about persistent udev to the answer?
http://www.linuxjournal.com/article/7316

I tried this on my cardreader. I created a new file /etc/udev/rules.d/91-local.rules
and added the following line:

KERNEL=="sd[c-f]*", GROUP="plugdev", MODE="0600"

All four devices sdc-sdf get plugdev group.

I am SO SORRY ! Really ! My bad....

Hey aus9 ! Thanks for the links!
(I corrected my previous post too)

I will read this too. But looks like the problem is not with the device node but automounting it.

Anyway, when I manage to solve this, I will make a small how-to here in this thread, for anyone interested.

see'ya,

a good practical way of limiting misuse is to tell the people using the machines that monitoring software has been installed on their computer and that it logs all activity to their account name.

'Any employee found to be involved in the misuse of company data will be prosecuted under the full extent of the law.'(!)

this method is a powerful preventative measure regardless of whether there is monitoring software installed or not

Yes, this work for the device node, but it is mounted anyway, because a root process mount this, not the user. Doesn't matter if I am member of group plugdev or not (and i am not). I tried even with mode=0000 and it is still mounted read-write to the user.

Hi aus9 ! Thanks to you (a reply to you) a become a Senior Member too! Cool !

Can't you set uid and gid in the fstab?

It works for me ... fstab line for sde1:

/dev/sde1 /media/sd vfat gid=410,umask=0707

410 is my plugdev group.

OK, refined it a bit.

etc/udev/rules.d/91-local.rules

KERNEL=="sd[c-f]*", GROUP="plugdev", MODE="0660"

fstab line

/dev/sde1 /media/sd vfat users,uid=0,gid=410,umask=0007 0 0

what happens if you run an external script from the UDEV rule to get the UID/GID and have it return a 0 or 1 for true/false, then just process that?

Hi jiml8 !

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.

I find this very interesting. One should think that after it used to be such a pain to get everyone to mount their USB sticks in an automated fashion it should be easy as pie to go back there.

I've tried to find a solution using this document: http://www.reactivated.net/writing_udev_rules.html

It was pretty helpful in the past. Now while I don't yet have a solution (just the suggestion to use the attribute 'Removable' to define which kind of block device not to mount), 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. You might therefore also want to identify the rules your distribution applies to removable devices and change or disable them.

Robin