[clug] Setting permission bit with a mount option

George at Clug Clug at goproject.info
Sun Mar 17 22:09:31 UTC 2019


Andrew,


Thanks for your suggestion of "Simply, always set the permissions of a
directory where you intend to mount a file system to 111." (i.e.
"---x--x--x")



This would work nicely with the simple mounting of shares that I have
worked with. I always disliked that when a share failed, and the
program using the share would still run and write into the directory
used for mounting the share.


George





On Monday, 18-03-2019 at 00:12 Andrew Steele via linux wrote:


Ah, a pet trick of mine may be of assistance ...

Don't know if it's any help in the context of the clustering software
you're using and the underlying mount point permissions, but there's a
very
useful trick we developed years ago (but surprisingly have never seen
mentioned elsewhere).

Simply, always set the permissions of a directory where you intend to
mount
a file system to 111.

There are three reasons for doing this:

1. It is the minimal permissions an underlying mount point directory
needs
to stop the mounted filesystem from behaving badly (requiring an
umount,
chmod, mount to fix).

2. Because it is an unusual permission to use, if you always apply
this to
all mount points, when you see a directory with this permission, you
have a
fair idea it's supposed to have something mounted on it.

3. It stops people writing into the underlying directory of the mount
fails
(useful in a cluster setting).

We started doing this around 20 years ago with Veritas disk groups of
disks
shared between Sun boxes. We would manually move a diskgroup from one
host
to another where both hosts could see the storage. All the places that
could have a file system mounted on it were given this permission. It
enabled us to see what was and wasn't mounted as it should, and
stopped
users writing where they shouldn't. A belt and braces approach.

Over the years I've always used it on all systems I manage. I've never
seen
an instance where it causes problems. It's saved me many
times.  Everyone
I've shown it to comes to the same conclusion I did - why doesn't
everyone
do this?  I can't claim the original idea as my own.

Andrew



On Sun, 17 Mar. 2019, 18:15 Brett Worth via linux, 
	* 
wrote:

> On 17/3/19 3:49 pm, Paul Wayper via linux wrote:
> > AFAIK the permissions on the directory the file system is mounted
on set
> the
> > permissions for the root of that file system.  Are you not
seeing that?
> >
> > I.e. unmount the file system, do `chmod 1777 /mnt/target`, mount
the file
> > system on `/mnt/target`, permissions for root directory should be
1777.
>
> Hi Paul.
>
> The permissions seen on the mounted mountpoint are the ones from the
root
> directory of the
> mounted filesystem.  They totally override the directory's
permissions.
>
> I was specifically looking for an entry I can put in the fstab
because the
> cluster
> management software I'm using has an XML definition of the
filesystem
> where you can
> specify the "options" column of the fstab entry.  The entry for
the
> mountpoint name
> doesn't include the permissions.
>
> This will have to be a post boot permission change I think.
>
> Brett
>
>
> --
>   /) _ _ _/_/ / / /  _ _//
>  /_)/
> --
> linux mailing list
> linux at lists.samba.org
> https://lists.samba.org/mailman/listinfo/linux
>
-- 
linux mailing list
linux at lists.samba.org
https://lists.samba.org/mailman/listinfo/linux


More information about the linux mailing list