> -------Original Message------- > From: RAGINI <[email protected]> > > Is it sensible to modify the mount options of the filesystem just so that a > user or group get the permissions to read and write, created by a > tool/platform, so that others cannot make changes to the files and > directories? >
That's a interesting question. As a reference, 'mount' options are listed at https://linux.die.net/man/8/mount You will note that the permissions you mention are the filesystem *independent* options, such as group Allow an ordinary (i.e., non-root) user to mount the filesystem if one of his groups matches the group of the device. This option implies the options nosuid and nodev (unless overridden by subsequent options, as in the option line group,dev,suid). owner Allow an ordinary (i.e., non-root) user to mount the filesystem if he is the owner of the device. This option implies the options nosuid and nodev (unless overridden by subsequent options, as in the option line owner,dev,suid). user Allow an ordinary user to mount the filesystem. The name of the mounting user is written to mtab so that he can unmount the filesystem again. This option implies the options noexec, nosuid, and nodev (unless overridden by subsequent options, as in the option line user,exec,dev,suid). users Allow every user to mount and unmount the filesystem. This option implies the options noexec, nosuid, and nodev (unless overridden by subsequent options, as in the option line users,exec,dev,suid). When the operations are reviewed, what we are allowing or dis-allowing a 'user' or 'group' is to either 'mount' or 'umount' the filesystem. This may be a activity that a DBA needs to perform and / or there is a script that is executed either by DBA or via crontab, given some "set of conditions". Hence, we need to evaluate what those "set of conditions" are which necessitate an action which is to "mount or umount". eg. restore a data file from the backup of the last 7 sessions. as a result the user or the script needs to mount each of the partitions one by one, then fire a search to locate the file. If the file is found, copy it out for the application, umount the filesystem and stop as the restoration task is complete. If the file is not found, umount this partition and mount another partition and repeate the process. Continue the tasks, until the backup for the last 7 sessions is checked. eg. there may be a similar activity related to a 'rmt' magentic tape. eg. another common scenario may be that a script needs to run 'fsck' on a particular filesystem. hence it would umount the filesystem, run 'fsck', fix the errors and / or selinux labels. Having satisfied there are no further errors, the filesystem is mounted again. Most of the above mentioned actions either done by an individual and most likely done by a automation script will require user, group mount privileges which are file system 'independent' options. Did that help ? warm regards Saifi.
