2

I have a mono application (on Ubuntu) that tails /var/log/messages and picks up USB insertions, and if that device is on a certain port, needs to partition, format, and mount it. Obviously this requires root permissions. I'm new to Linux, and I'm wondering what the "correct" way is accomplish this.

Is it better to run my application as root all the time? Or is it better (or possible) to give my application permissions to unmount, parted, mkfs, and mount and any other root-only process I need?

Background:
Once mounted, some specific customer requested files will be loaded to the drive. Each drive is unique, so cloning will not work, and I will be supporting hundreds of drives per week, so I need it to be as automated as possible. I realize this is dangerous, so yes, I will put a warning on the machine that all drives will be formatted. I'm using mono because it fits nicely with the larger application which is written in C# .net.

2
  • 1
    I think some custom udev rules would be the best way to hook into USB insertions. The rule would call a script to perform those actions, or call your program.
    – Keith
    Apr 23, 2011 at 19:00
  • Thanks to everyone who answered. It looks like I need to read up on device security to get a better grasp of what is going on there. Both answers helped me get through the wall and moving again, and I would accept them both if I could. Cheers! Apr 25, 2011 at 6:10

2 Answers 2

2

Actually you don't have to have root permissions to do that. If fact I would highly recomend not letting anything run as root. Here is the safest way I would suggest.

  1. Write a one line shell script that does a chown on the device node to the user your mono app is running as or chmod to open up world or group permissions sufficient for your app to modify the device.
  2. Save the script in /usr/local/bin owned by root and NOT writable by users.
  3. Add a rule to sudoers that allows the user your mono app runs the script you just created.
  4. In your app after it detects a device, first run that script with sudo so that the device is read/writeable by your user.
  5. Do all your actions on the device as a user!

Note: Do not give your app sudo access to chmod, chown, fdisk or any other such administrative tools, only the protected single purpose script you wrote that opens up permisions on just your one device.

2
  • Great advice and thank you so much for pointing me in the right direction. I chown'd the device (chown user /dev/sdc), and now I can partition the drive as my user. I get an error however, "Partition(s) on /dev/sdc have been written, but we have been unable to inform the kernel of the change, probably because it/they are in use." I'm assuming this is because my user doesn't have permissions to inform the kernel. Is it safe to ignore this? Apr 24, 2011 at 19:16
  • 1
    @Ryan The best way to fix that is to install parted and use its partprobe /dev/sdc command as root through sudo after editing the partition table, the only thing the command does is order the kernel to reread the partition table, so it's theoretically safer than access to fdisk itself.
    – DerfK
    Apr 24, 2011 at 19:45
0

Adding to Caleb's answer, for mount and umount you won't need root privileges to do those as long as you set up /etc/fstab with the device names and mountpoints for each with "user,noauto" (in addition to any other options you need. user gives normal users permission to mount and umount the device, noauto tells the boot process not to try and mount all of them at startup... the fsck and dump columns should be 0, as well). You'll need to create one entry and directory for each device (eg /mnt/sda1 to go with /dev/sda1).

If these are going to be FAT formatted, you may be able to ignore mounting completely. After using mkfs.msdos to create the filesystem, use mtools to edit the filesystem directly. Looking through the mtools documentation, there is at least one temporary file (I found .mcwd) that make working with multiple filesystems at the same time difficult (each process will need to set a unique $MCWD environment variable to point to a different location or filename for this file), so be sure to read the documentation throughly.

With the ext2 filesystem, a new can of worms is opened: user and group ownership and file permissions. The easiest way to get around this is by using a script to chown the mount point after the filesystem is mounted just like the script to chown the device file. Then the user can write the files in and use chmod to set permissions appropriately. The problem here is that the recipient of the drive may not have a matching user, but as long as you make sure the "other" read/write/execute bits are correct and you avoid using the suid/sgid bits, this is mostly a cosmetic issue (unless they actually do have a user that matches your uid, and then that person will be able to write to the drive unless the recipient changes the permissions immediately).

3
  • DerfK, thanks for the response. I'm not sure this would work for me because we get our flash drives out of a giant box of drives and the application never sees the same drive twice. The drive manufacturer and types vary as well. FWIW, I'm using ext2 format. Apr 24, 2011 at 19:21
  • The fstab idea works because USB drives are consistently named with scsi drive device files, so you can create a list of these in your fstab file with user mounting permissions (starting, apparently, with /dev/sdc1 and /mnt/sdc1/.
    – DerfK
    Apr 24, 2011 at 19:49
  • Your suggestion works for mounting drives as a user, but the problem here is the guy wants to automatically partition and format them from his program as well as mounting and doing something with them. To do this, the device nodes need to be user accessible, not just the mount point.
    – Caleb
    Apr 25, 2011 at 12:50

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .