Bug 246459 - Autofs with nis map writing access on multi mointpoint
Autofs with nis map writing access on multi mointpoint
Status: CLOSED DEFERRED
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
6
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Steve Dickson
Fedora Extras Quality Assurance
bzcl34nup
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-07-02 09:54 EDT by bbo
Modified: 2008-04-04 08:14 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-04-04 08:14:34 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description bbo 2007-07-02 09:54:58 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4

Description of problem:
using a NIS map or a local autofs map, on a same exports host and between to directory with de same root, if there is 2 differents access rights (read and write) on each mount only the read access work when it was invoked first.

i am sorry for my poor english




Version-Release number of selected component (if applicable):
autofs-5.0.1-0.rc3.29

How reproducible:
Always


Steps to Reproduce:
with a nis map like that (/etc/auto.custom):

soft   -rw,hard,intr host:/home/soft
private   -ro,soft,intr host:/home/private

if you access first to the private mount point and on a second time to the soft mount point, autofs keep the read access right an we can't write to the soft directory.

example:

cd  /S/private
cd  /S/soft
touch foo
touch: cannot touch 'foo': read-only file syste


Actual Results:
the same map work on others Linux distributions ans on Sun workstations

Expected Results:


Additional info:
Comment 1 bbo 2007-07-02 09:57:10 EDT
I have tested, Fedora core 6 i386, x86_64 and Fedora core 7 x86_64 with the same
wrong results
Comment 2 Ian Kent 2007-07-02 10:18:19 EDT
(In reply to comment #0)
> 
> Description of problem:
> using a NIS map or a local autofs map, on a same exports host and between to
directory with de same root, if there is 2 differents access rights (read and
write) on each mount only the read access work when it was invoked first.
> 
> i am sorry for my poor english

What I think you're saying is that multiple mounts for the
same NFS exported filesystem always have the same options
as the first mounted instance, regardless of the options
requested on second and subsequent mounts.

Is my understanding correct?

Ian
Comment 3 bbo 2007-07-02 10:53:18 EDT
it's exactly that i mean

bertrand
Comment 4 bbo 2007-07-02 10:58:21 EDT
the exported filesystem is located on a NAS emc server. 
Comment 5 Ian Kent 2007-07-02 10:59:57 EDT
(In reply to comment #3)
> it's exactly that i mean

That's a known issue with upstream kernel NFS client.
People are working to fix it but I'm not sure when or
if this will reach FC6.

Ian
Comment 6 bbo 2007-07-02 11:00:28 EDT
(In reply to comment #2)
> (In reply to comment #0)
> > 
> > Description of problem:
> > using a NIS map or a local autofs map, on a same exports host and between to
> directory with de same root, if there is 2 differents access rights (read and
> write) on each mount only the read access work when it was invoked first.
> > 
> > i am sorry for my poor english
> 
> What I think you're saying is that multiple mounts for the
> same NFS exported filesystem always have the same options
> as the first mounted instance, regardless of the options
> requested on second and subsequent mounts.
> 
> Is my understanding correct?
> 
> Ian
> 
yes it is
Comment 7 bbo 2007-07-02 11:02:59 EDT
(In reply to comment #5)
> (In reply to comment #3)
> > it's exactly that i mean
> 
> That's a known issue with upstream kernel NFS client.
> People are working to fix it but I'm not sure when or
> if this will reach FC6.
> 
> Ian
> 
thank's

so i am waiting for the next release to correct this bugs

Bertrand
Comment 8 Ian Kent 2007-07-02 11:36:48 EDT
(In reply to comment #7)
> (In reply to comment #5)
> > (In reply to comment #3)
> > > it's exactly that i mean
> > 
> > That's a known issue with upstream kernel NFS client.
> > People are working to fix it but I'm not sure when or
> > if this will reach FC6.
> > 
> > Ian
> > 
> thank's
> 
> so i am waiting for the next release to correct this bugs

I'm not sure you understood what I meant.
Let me say it again, slightly differntly.

This isn't an autofs problem and there's nothing autofs
can do to change the behavior.

The change has been present in the Linux kernel since
early in the 2.6 series and only fairly recently has
the number of reports warranted people to work on
fixing it. Some believe this is the correct behavior
because allowing different mount options on the client
for the same filesystem leads to a false sense of
security as this can be easily subverted.

At least that's something like what I got from the
discussions I've seen.

If you'd like to request that something be done
about this for FC6 then we should change the component
of this bug to be "kernel" instead of "autofs".

Ian
Comment 9 Bug Zapper 2008-04-04 03:26:29 EDT
Fedora apologizes that these issues have not been resolved yet. We're
sorry it's taken so long for your bug to be properly triaged and acted
on. We appreciate the time you took to report this issue and want to
make sure no important bugs slip through the cracks.

If you're currently running a version of Fedora Core between 1 and 6,
please note that Fedora no longer maintains these releases. We strongly
encourage you to upgrade to a current Fedora release. In order to
refocus our efforts as a project we are flagging all of the open bugs
for releases which are no longer maintained and closing them.
http://fedoraproject.org/wiki/LifeCycle/EOL

If this bug is still open against Fedora Core 1 through 6, thirty days
from now, it will be closed 'WONTFIX'. If you can reporduce this bug in
the latest Fedora version, please change to the respective version. If
you are unable to do this, please add a comment to this bug requesting
the change.

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we are following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

And if you'd like to join the bug triage team to help make things
better, check out http://fedoraproject.org/wiki/BugZappers

Note You need to log in before you can comment on or make changes to this bug.