[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
kern/73146: cannot chmod mount point for read-only filesystem
- Subject: kern/73146: cannot chmod mount point for read-only filesystem
- From: ceri at FreeBSD.org (Ceri Davies)
- Date: Tue Oct 26 01:04:44 2004
The following reply was made to PR kern/73146; it has been noted by GNATS.
From: Ceri Davies <ceri_(_at_)_FreeBSD_(_dot_)_org>
To: FreeBSD Gnats Submit <freebsd-gnats-submit_(_at_)_FreeBSD_(_dot_)_org>
Subject: Re: kern/73146: cannot chmod mount point for read-only filesystem
Date: Tue, 26 Oct 2004 09:03:49 +0100
Adding to audit trail, from kern/73148:
From: Gregory Bond <gnb_(_at_)_itga_(_dot_)_com_(_dot_)_au>
To: Nehal <nehalmistry_(_at_)_gmx_(_dot_)_net>
Subject: kern/73148: Re: kern/73148: cannot chmod mount point for read-only filesystem
Date: Tue, 26 Oct 2004 15:22:44 +1000
>the chmod should only be denied for files/subdirectories
>inside the mount point, not the mount point itself.
Um, this is never how Unix has operated. After a mount(), the
underlying inode of the mount point is completely inacessible and hidden
by the root inode of the mounded FS until an unmount is done. It's been
this way since V7 or earlier. The FreeBSD man page for mount(2) hides
this a bit with some flowery language ("swept under the carpet"), but
consider the wording from Solaris 2.8 man page:
The mount() function requests that a removable file system
contained on the block special file identified by spec be
mounted on the directory identified by dir. The spec and dir
arguments are pointers to path names. After a successful
call to mount(), all references to the file dir refer to the
root directory on the mounted file system.
In other words, this beahviour is as designed.