[clug] Setting permission bit with a mount option

George at Clug Clug at goproject.info
Sun Mar 17 22:01:36 UTC 2019


Brett,


Apologies I don't know that much about mount to offer much assistance
to you. I have never had the need to do interesting things with
directories.


You said, "cluster management software", I am curious about your
cluster. It is an area I have not as yet need to work with. Would you
like to give a talk on clustering? I would definitely be interested.


What it is that you are attempting to mount?  (i.e. is it a share, a
partition?  You mentioned a "cluster", so I am guessing your mounting
a share of some kind?)


Can you provide us with an example of your fstab line that is doing
the mount which is having the issue?


When doing some research today, I found it interesting to learn 

1) that directories are actually just files
http://www.grymoire.com/Unix/Permissions.html, 

2) most modern Linux systems will not allow you to access the
directory "file" directly (I was hoping to open it with a hex editor,
of course there are ways).  



http://teaching.idallen.com/cst8207/14w/notes/450_file_system.html
The ROOT directory inode has no name because there is no directory
above it to give it one! Every other directory except ROOT has a name
because there is a directory inode above it that contains its name.


If my research and understanding is correct, all permissions are
stored in the partition inside the directory file, and mounting has
nothing to do with permissions. Not sure how this affects/works with
the root partition, I guess the root directory inode has a special way
to be identified by the linux file system without required a file
name, and after that all other child directories are identified by the
directory's filename?


You said "The permissions seen on the mounted mountpoint are the ones
from the root directory of the mounted filesystem. ", and from the
above research, that does seem to be how directories and permissions
work, they are recorded in the directory "file".



Are you running SELinux?



Do all users/groups exist, on all relevant systems?  (I ask this as
when dealing with shares, I have had issues when the sharing server
and the mounting client did not have the same groups and users)


George





















Below here are links that I used for my research, recorded for my
benefit (and anyone who may find them interesting).



http://www.grymoire.com/Unix/Permissions.html

"...directories are files as well. The file is not stored "inside" a
directory. Files are stored in data blocks scattered alll over the
disk partition. The directory is a special file that contains access
information about all of the files references "inside" the
directory..."




http://www.grymoire.com/Unix/Permissions.html


 Note that you can change permissons of files you own. That is, you
can remove all permissions of a file, and then add them back again.
You can make a file "read only" to protect it. However, making a file
read only does not prevent you from deleting the file. That's because
the file is in a directory, and directories also have read, write and
execute permission. And the rules are different. Read on. 



BASIC DIRECTORY ATTRIBUTES - READ, WRITE AND SEARCH [1]



Directories use these same permissions, but they have a different
meaning. Yes, very different meanings. This is classic Unix: terse,
flexible and very subtle. Okay - let's cover the basic directory
permissions. 



READ PERMISSION ON A DIRECTORY [2]



 If a directory has read permission, you can see what files are in the
directory. That is, you can do an "ls" command and see the files
inside the directory. However, read permission of a directory does not
mean you can read the contents of files in the directory. 



WRITE PERMISSION ON A DIRECTORY [2]



 Write permission means you can add a new file to the directory. It
also means you can rename or move files in the directory. 



EXECUTE PERMISSION ON A DIRECTORY [2]



Execute allows you to use the directory name when accessing files
inside that directory. The "x" permission means the directory is
"searchable" when searching for executables. If it's a program, you
can execute the program. 



 LET'S EXAMINE ALL THIS A BIT CLOSER. 



This makes sense when you realise that directories are files as well.
The file is not stored "inside" a directory. Files are stored in data
blocks scattered alll over the disk partition. The directory is a
special file that contains access information about all of the files
references "inside" the directory. 



Suppose you have read access to a directory, but you do not have read
access to the files in the directory. You can still read the
directory, or more corectly, the status information for that file, as
returned by the _stat_() system call. That is, you can see the file's
name, permissions, size, access times, owner and group, and number of
links because you have access to the directory. The file itself is
stored elsewhere on the disk (this spot is identified by the i-node
number.) The "ls -i" command shows the i-node number for a file. 



Write permission in a directory allows you to change the contents of a
directory. Because the name of the file is stored in the directory,
and not in the file, write permission in a directory allows renaming
or deletion of files and does not require write permission of the
file. To be specific, if someone has write permission to your home
directory, they can rename or delete your .login file and put a new
file in its place. The permissions of your .login file do not matter.
Someone can rename a file even if they can't read the contents of a
file. 



Execute permission on a directory is sometimes called search
permission. If you found a directory that gave you execute permission,
but not read permission, you could use any file in that directory.
However, you must know the name. You cannot look inside the directory
to find out the names of the files. Think of this type of directory as
a black box. You can throw filenames at this directory, and sometimes
you find a file, sometimes you don't. 




https://docs.oracle.com/cd/E19683-01/816-4883/secfile-69/index.html


SPECIAL FILE PERMISSIONS (SETUID, SETGID AND STICKY BIT)



Three special types of permissions are available for executable files
and public directories. When these permissions are set, any user who
runs that executable file assumes the user ID of the owner (or group)
of the executable file. 



You must be extremely careful when you set special permissions,
because special permissions constitute a security risk. For example, a
user can gain superuser privileges by executing a program that sets
the user ID (UID) to root. Also, all users can set special permissions
for files they own, which constitutes another security concern.



You should monitor your system for any unauthorized use of the setuid
and setgid permissions to gain superuser privileges. To search for and
list all of the files that use these permissions, see How to Find
Files With setuid Permissions [3]. A suspicious listing grants
ownership of such a program to a user rather than to root or bin. 









https://searchdatacenter.techtarget.com/tip/Samba-3-Windows-file-and-directory-ACLs



Within the UNIX operating system, a directory is a file that contains
references to the files within it. A directory is a special type of
file that is of type "d." 




 [4]


https://www.tutorialspoint.com/unix/unix-quick-guide.htm


A directory is a file the solo job of which is to store the file names
and the related information. All the files, whether ordinary, special,
or directory, are contained in directories.



Unix uses a hierarchical structure for organizing files and
directories. This structure is often referred to as a directory tree.
The tree has a single root node, the slash character (/), and all
other directories are contained below it.








THE DIRECTORIES . (DOT) AND .. (DOT DOT)



The filename . (dot) represents the current working directory; and the
filename .. (dot dot) represents the directory one level above the
current working directory, often referred to as the parent directory.











https://en.wikipedia.org/wiki/File_system_permissions
Changing permission behavior with setuid, setgid, and sticky bits

Unix-like systems typically employ three additional modes. These are
actually attributes but are referred to as permissions or modes. These
special modes are for a file or directory overall, not by a class,
though in the symbolic notation (see below) the setuid bit is set in
the triad for the user, the setgid bit is set in the triad for the
group and the sticky bit is set in the triad for others.

    The set user ID, setuid, or SUID mode. When a file with setuid
is executed, the resulting process will assume the effective user ID
given to the owner class. This enables users to be treated temporarily
as root (or another user).
    The set group ID, setgid, or SGID permission. When a file with
setgid is executed, the resulting process will assume the group ID
given to the group class. When setgid is applied to a directory, new
files and directories created under that directory will inherit their
group from that directory. (Default behaviour is to use the primary
group of the effective user when setting the group of new files and
directories, except on BSD-derived systems which behave as though the
setgid bit is always set on all directories (See Setuid).)
    The sticky mode. (Also known as the Text mode.) The classical
behaviour of the sticky bit on executable files has been to encourage
the kernel to retain the resulting process image in memory beyond
termination; however such use of the sticky bit is now restricted to
only a minority of unix-like operating systems (HP-UX and UnixWare).
On a directory, the sticky permission prevents users from renaming,
moving or deleting contained files owned by users other than
themselves, even if they have write permission to the directory. Only
the directory owner and superuser are exempt from this.

These additional modes are also referred to as setuid bit, setgid bit,
and sticky bit, due to the fact that they each occupy only one bit. 










Where filesystems partitions can be ? block volumes iSCSI and
paravirtualized attachment types.


sudo blkid


https://docs.cloud.oracle.com/iaas/Content/Block/References/fstaboptions.htm


USE THE _NETDEV AND NOFAIL OPTIONS

By default, the /etc/fstab file is processed before the initiator
starts. To configure the mount process to initiate before the volumes
are mounted, specify the _netdev option on each line of the /etc/fstab
file. 



When you create a custom image of an instance where the volumes,
excluding the root volume, are listed in the /etc/fstab file,
instances will fail to launch from the custom image. To prevent this
issue, specify the nofail option in the /etc/fstab file.







https://www.ibm.com/support/knowledgecenter/en/prodconn_1.0.0/com.ibm.scenarios.wmqwasha.doc/topics/ha_mq_sharedmsgstore.htm?cp=SSFKSJ_8.0.0


	* On the NFS server, create a user called mqm. In the command line,
enter useradd mqm.
	* Create a group that is called mqm, enter groupadd mqm.
	* Add the mqm user to the mqm group. Enter usermod -g mqm mqm.
	* Start the NFS services, enter chkconfig nfs on. The NFS services 2,
3, 4, and 5 must be on. Check the status of the services, enter
chkconfig --list nfs.nfs 0:off 1:off 2:on 3:on 4:on 5:on 6:off 
	* Create the top-level directory to share. In the command line, enter
mkdir /var/mqm.

	* Edit the fstab configuration file. In the command line, enter vi
/etc/fstab. 
Why? 



	* Add an entry for the new shared directory. At the end of the file,
type /dev/basevg/varmqm /var/mqm ext3defaults 1 2. Use the Tab key to
match the format of the previous entries.
Why? 
	* Press the Escape key and enter:wq.


https://www.howtogeek.com/howto/38125/htg-explains-what-is-the-linux-fstab-and-how-does-it-work/


http://www.grymoire.com/Unix/Permissions.html


https://unix.stackexchange.com/questions/154119/when-did-directories-stop-being-readable-as-files

https://en.wikipedia.org/wiki/File_system_permissions
Changing permission behavior with setuid, setgid, and sticky bits

Unix-like systems typically employ three additional modes. These are
actually attributes but are referred to as permissions or modes. These
special modes are for a file or directory overall, not by a class,
though in the symbolic notation (see below) the setuid bit is set in
the triad for the user, the setgid bit is set in the triad for the
group and the sticky bit is set in the triad for others.

    The set user ID, setuid, or SUID mode. When a file with setuid
is executed, the resulting process will assume the effective user ID
given to the owner class. This enables users to be treated temporarily
as root (or another user).
    The set group ID, setgid, or SGID permission. When a file with
setgid is executed, the resulting process will assume the group ID
given to the group class. When setgid is applied to a directory, new
files and directories created under that directory will inherit their
group from that directory. (Default behaviour is to use the primary
group of the effective user when setting the group of new files and
directories, except on BSD-derived systems which behave as though the
setgid bit is always set on all directories (See Setuid).)
    The sticky mode. (Also known as the Text mode.) The classical
behaviour of the sticky bit on executable files has been to encourage
the kernel to retain the resulting process image in memory beyond
termination; however such use of the sticky bit is now restricted to
only a minority of unix-like operating systems (HP-UX and UnixWare).
On a directory, the sticky permission prevents users from renaming,
moving or deleting contained files owned by users other than
themselves, even if they have write permission to the directory. Only
the directory owner and superuser are exempt from this.

These additional modes are also referred to as setuid bit, setgid bit,
and sticky bit, due to the fact that they each occupy only one bit. 




































On Friday, 15-03-2019 at 12:32 Brett Worth via linux wrote:


Does anyone know if it is possible to set the mode bits of a
filesystem's root at mount time?

i.e. I'd like to have something in the fstab options column of an ext3
entry like
"defaults,mode=1777" so that when the filesystem is mounted you end up
with "drwxrwxrwt".

I know that "mode=" and "permissions=" are not right.  Does anyone
know if this is possible?

I could change it later in the boot process but having it in fstab
seems more correct.

Brett

-- 
  /) _ _ _/_/ / / /  _ _//
/_)/

Links:
------
[1] http://www.grymoire.com/Unix/Permissions.html#toc-uh-1
[2] http://www.grymoire.com/Unix/Permissions.html#TOC
[3] https://docs.oracle.com/cd/E19683-01/816-4883/6mb2joatb/index.html
[4] https://www.tutorialspoint.com/unix/unix-quick-guide.htm


More information about the linux mailing list