Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 630
  • Last Modified:

rw vs. umask in mount call, and coditional mounting

Although I know the answer to the first part of this question, the
issue is still not 100% clear.  The first question is, what is the
difference between the option rw vs. umask in a mount call?  Let me
explain the entire situation since it leads to question number 2.

I have a usb card reader that when plugged into my system is either
recognized as /dev/sda1 or sometimes (if I already have something
plugged in) as /dev/sdb1.
This card is formatted as fat32 so that I can write to it using Linux.
 I have disabled supermount from loading this drive in /etc/fstab
because I don't like supermount for some reason I forgot a while ago.

Ok, so my /etc/fstab reads
/dev/sda1 /mnt/flashcard vfat user,umask=000,rw 0 0

The thing is that I don't need rw to be able to write to this mount
point.  The mount man pages say the following about the rw option:

rw     Mount the file system read-write.

That is it.  I guess my question goes a bit further than the basic
difference.  Not only do I want to know what is the difference between
rw and umask but also where can I get this information from my system
so that I don't have to bother people on the internet.  I've tryied
the info call and in it there is no mention that the rw option is
valid for mounting vfat nor for any of the explicitly mentioned
filesystems.  The documentation, in my opinion, does not explain when
and where to use the rw option.  Any suggestions?

Although it may be that supermount would take care of this, I would
like to know if there is a way to conditionally mount devices.  The
reason for this is that, like I said earlier, my card reader is
mounted on /dev/sda1 or /dev/sdb1.  Would there be a way to have a
mount definition in /etc/fstab so that it figures out where the card
reader is recognized?
0
bisonfur37
Asked:
bisonfur37
  • 2
1 Solution
 
jlevieCommented:
The rw option to mount says to allow writes to the mounted volume, as opposed to using ro for a read only mount.

The umask determines what permissions will be set on the mount point (/mnt/flashcard) which in turn will determine who will be able to do what with the content of the mounted volume. The umask turns bits in the protection mask off, so 000 -> rwxrwxrwx, 022 -> rwxr-xr-x, etc.

> Would there be a way to have a mount definition in /etc/fstab so that it figures out where the card
> reader is recognized?

No, but I think it would be possible to do this with a hotplug script.
0
 
bisonfur37Author Commented:
I understand your explanation although it seems that setting the umask will cover all of the scenarios and rw is extraneous and also vague.  Setting rw allows writes to the mounted volume but it does not delegate who can write to the volume as umask does.  Was rw meant to be used by fat filesystems where user permissions were never an issue; ie, you could only set a volume as 'read-only' or not 'read-only' in which case you could write to it.  Any more on the subject?
0
 
jlevieCommented:
What the rw/ro option does is to allow/deny writes to the mounted file system. That's independent of user permissions as set by the umask.  The file system type of the volume determines how the umask is to be interpreted. A file system like FAT, FAT32, NTFS, or an SMB mount does not contain embedded permissions information attached to each file/dir the way an EXT2/3, XFS, RieserFS, NFS, etc.. file system does. So when the mounted volume is one of those that doesn't have per-file/per-dir ownership & permissions the umask serves that purpose for the content of the volume.

The rw/ro option operates a a level below file permissions. There are times when one might want to mount a volume read only, either to prevent any change in the volume contents, or because the media is inheritly read only (i.e., a CD).
0

Featured Post

Free Tool: Path Explorer

An intuitive utility to help find the CSS path to UI elements on a webpage. These paths are used frequently in a variety of front-end development and QA automation tasks.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now