P? to , 08/01/2004 klokka 13:31, skreiv
[email protected]:
> Special vfsmount mounted somewhere; has no superblock associated with
> it; attempt to step on it triggers event; normal result of that event
> is to get a normal mount on top of it, at which point usual chaining
> logics will make sure that we don't see the trap until it's uncovered
> by removal of covering filesystem. Trap (and everything mounted on
> it, etc.) can be removed by normal lazy umount.
>
> Basically, it's a single-point analog of autofs done entirely in VFS.
> The job of automounter is to maintain the traps and react to events.
What if the trap is set by the filesystem? I'm thinking about AFS
volumes and NFSv4 migration events here.
Both these need something that goes beyond the current autofs "daemon
waiting on top of a single trap" thinking.
In the NFSv4 migration case we can be walking down the filesystem patch
and enter a directory where we are basically told by the server that
"this volume has been moved" and are given a list of replicated
servername/pathname fields. Those then need to be interpreted in
userland by means of an upcall of some sort, and the new volume needs to
be mounted.
Neither autofs3 nor autofs4 can currently help us do this, because we
don't a priori have a complete list of directories on which to start a
bunch of "automount" daemons (and it wouldn't help anyway since a server
failover event etc. might cause the list to change).
Setting up our own traps, however, and then doing the upcall by means of
an exec & an "intelligent" mount program (as Mike & co. propose) OTOH,
would very much simplify matters, since that allows us to do simple
string parameter passing from the kernel to direct how the mount is to
be set up.
It still leaves the final policy decisions of which server to mount &
where in userland.
Finally, because the upcall is done in the user's own context, you avoid
the whole problem of automounter credentials that are a constant plague
to all those daemon-based implementations when working in an environment
where you have strong authentication.
If anyone wants evidence of how broken the whole daemon thing is, then see
the workarounds that had to be made in RFC-2623 to disable strong
authentication for GETATTR etc. on the NFSv2/v3 mount point.
Cheers,
Trond
[email protected] wrote:
>
> Finally, because the upcall is done in the user's own context, you avoid
> the whole problem of automounter credentials that are a constant plague
> to all those daemon-based implementations when working in an environment
> where you have strong authentication.
> If anyone wants evidence of how broken the whole daemon thing is, then see
> the workarounds that had to be made in RFC-2623 to disable strong
> authentication for GETATTR etc. on the NFSv2/v3 mount point.
>
It's not broken as much as what you want to do is outside the scope of
automount. automount is one particular user of these facilities, and as
you correctly point out, it can't solve the problems for all of them.
The right thing for AFS and NFSv4 is clearly to do something different.
Mount traps by themselves are not sufficient for automount, which is why
I think we will always have a special "autofs" filesystem, for the
simple reason that automount in typical use doesn't either have an a
priori complete list of directories! Even with ghosting you might find
that you're accessing a new key which has not yet been ghosted, and it
needs to be handled correctly. Additionally, not all map types can be
enumerated, and some aren't even finite in size (consider /net, program
maps and wildcard map entries.) Thus, for indirect mountpoints you
still need a filesystem which can trap on non-enumerated entries.
That being said, mount traps in particular, and possibly this "trap
filesystem" are more generic kernel facilities which should be of use to
other things than automount. AFS/NFSv4 are the obvious examples, quite
possibly other things like intermezzo might be interested, and we don't
want to have to reinvent the wheel every time.
-hpa
>> If anyone wants evidence of how broken the whole daemon thing is, then
>> see the workarounds that had to be made in RFC-2623 to disable strong
>> authentication for GETATTR etc. on the NFSv2/v3 mount point.
>>
>
> It's not broken as much as what you want to do is outside the scope of
> automount. automount is one particular user of these facilities, and as
> you correctly point out, it can't solve the problems for all of them.
> The right thing for AFS and NFSv4 is clearly to do something different.
My point is that the above problem crops up in almost *all* combinations
of automounter daemon with remote filesystem and strong authentication.
In order to correctly mount the remote filesystem, the automounter
itself needs a minimum set of remote privileges (typically it needs to be
able
to browse the remote filesystem).
RFC-2623 describes how to add RPCSEC_GSS to NFSv2/v3. The
workarounds (hacks really) that I refer to above had to be deliberately
added in order to make Sun's automounter work in this environment.
The alternative would have been to have a global "machine" credential
for use by the automounter when browsing /net. Hardly secure...
> That being said, mount traps in particular, and possibly this "trap
> filesystem" are more generic kernel facilities which should be of use to
> other things than automount. AFS/NFSv4 are the obvious examples, quite
> possibly other things like intermezzo might be interested, and we don't
> want to have to reinvent the wheel every time.
Certainly. I believe CIFS might also have a similar mechanism.
Cheers,
Trond
[email protected] wrote:
>
> My point is that the above problem crops up in almost *all* combinations
> of automounter daemon with remote filesystem and strong authentication.
> In order to correctly mount the remote filesystem, the automounter
> itself needs a minimum set of remote privileges (typically it needs to be
> able to browse the remote filesystem).
>
> RFC-2623 describes how to add RPCSEC_GSS to NFSv2/v3. The
> workarounds (hacks really) that I refer to above had to be deliberately
> added in order to make Sun's automounter work in this environment.
> The alternative would have been to have a global "machine" credential
> for use by the automounter when browsing /net. Hardly secure...
>
My point is that it's what you get for having an automounter.
We can't solve Sun's designed-in braindamage, unfortunately. This is
partially why I'd like people to consider the scope of what automounting
does; there are tons of policy issues not all of which are going to be
appropriate in all contexts. To some degree, if you have to have an
automounter you have already lost.
Also, your global machine credential is to some degree "all the security
you get." Any security which isn't enforced by the filesystem driver
doesn't exist in a Unix environment; in particular there is no security
against root. Stupid tricks like remapping uid 0 are just that; stupid
tricks without any real security value. You know this, of course.
However, if you think the automounter doesn't have the privilege to
access the remote server but the user does, then that's false security.
Linux at this point has no ability to support actual user-mounted
filesystems. There are things that could be done to remedy this, but it
would require massive changes to every filesystem driver as well as to
the VFS. Would it be desirable? Absolutely. However, it's partially
the quagmire that got the HURD stuck for a very long time, even though
they had the huge advantage of being able to run their filesystem
drivers in a nonprivileged context.
-hpa
J. Bruce Fields wrote:
>
> On Thu, Jan 08, 2004 at 01:13:24PM -0800, H. Peter Anvin wrote:
>
>>Also, your global machine credential is to some degree "all the security
>>you get." Any security which isn't enforced by the filesystem driver
>>doesn't exist in a Unix environment; in particular there is no security
>>against root.
>
> I only have to trust root on the nfs client machines that I actually
> use. (In fact, I only really have to trust those machines with a
> short-lived ticket, preventing even those machines from impersonating me
> beyond a limited time.)
>
And when that ticket expires, you better have NFS itself know how to
renew its credentials, or you're up the creek. Nothing that autofs can
help you with.
>
>>Stupid tricks like remapping uid 0 are just that; stupid
>>tricks without any real security value. You know this, of course.
>>However, if you think the automounter doesn't have the privilege to
>>access the remote server but the user does, then that's false security.
>
> If the server requires kerberos credentials that only a user has, then
> the automounter can't do anything until the user coughs up those
> credentials.
>
True, but giving them to a privileged daemon is no different that giving
them to the kernel in that way.
-hpa
On Thu, Jan 08, 2004 at 01:13:24PM -0800, H. Peter Anvin wrote:
> Also, your global machine credential is to some degree "all the security
> you get." Any security which isn't enforced by the filesystem driver
> doesn't exist in a Unix environment; in particular there is no security
> against root.
I only have to trust root on the nfs client machines that I actually
use. (In fact, I only really have to trust those machines with a
short-lived ticket, preventing even those machines from impersonating me
beyond a limited time.)
> Stupid tricks like remapping uid 0 are just that; stupid
> tricks without any real security value. You know this, of course.
> However, if you think the automounter doesn't have the privilege to
> access the remote server but the user does, then that's false security.
If the server requires kerberos credentials that only a user has, then
the automounter can't do anything until the user coughs up those
credentials.
--Bruce Fields
H. Peter Anvin wrote:
>[email protected] wrote:
>
>
>>Finally, because the upcall is done in the user's own context, you avoid
>>the whole problem of automounter credentials that are a constant plague
>>to all those daemon-based implementations when working in an environment
>>where you have strong authentication.
>>If anyone wants evidence of how broken the whole daemon thing is, then see
>>the workarounds that had to be made in RFC-2623 to disable strong
>>authentication for GETATTR etc. on the NFSv2/v3 mount point.
>>
>>
>>
>
>It's not broken as much as what you want to do is outside the scope of
>automount. automount is one particular user of these facilities, and as
>you correctly point out, it can't solve the problems for all of them.
>The right thing for AFS and NFSv4 is clearly to do something different.
>
>
>
If automount is going to be mounting NFS shares for users, I don't see
how this is out of scope.
>Mount traps by themselves are not sufficient for automount, which is why
>I think we will always have a special "autofs" filesystem, for the
>simple reason that automount in typical use doesn't either have an a
>priori complete list of directories! Even with ghosting you might find
>that you're accessing a new key which has not yet been ghosted, and it
>needs to be handled correctly. Additionally, not all map types can be
>enumerated, and some aren't even finite in size (consider /net, program
>maps and wildcard map entries.) Thus, for indirect mountpoints you
>still need a filesystem which can trap on non-enumerated entries.
>
>
>
Yup.
>That being said, mount traps in particular, and possibly this "trap
>filesystem" are more generic kernel facilities which should be of use to
>other things than automount. AFS/NFSv4 are the obvious examples, quite
>possibly other things like intermezzo might be interested, and we don't
>want to have to reinvent the wheel every time.
>
>
>
I could see AFS using these mounttraps, however I don't see any benefit
for NFS. If anything, the migration issue is about getting rid of the
daemon, not mounttraps. The issues I think Trond is putting forward are:
a) The kernel needs to initiate a remount, but doesn't have nameservice
functionality.
b) User credentials are needed to perform the initial mount itself
because some servers don't allow non-authenticated calls to the MOUNT
program, keeping the system from grabbing a root filehandle.
--
Mike Waychison
Sun Microsystems, Inc.
1 (650) 352-5299 voice
1 (416) 202-8336 voice
mailto: [email protected]
http://www.sun.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTICE: The opinions expressed in this email are held by me,
and may not represent the views of Sun Microsystems, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
H. Peter Anvin wrote:
>My point is that it's what you get for having an automounter.
>
>We can't solve Sun's designed-in braindamage, unfortunately. This is
>partially why I'd like people to consider the scope of what automounting
>does; there are tons of policy issues not all of which are going to be
>appropriate in all contexts. To some degree, if you have to have an
>automounter you have already lost.
>
>
However, we can solve Linux's designed-in braindamage.
>Also, your global machine credential is to some degree "all the security
>you get." Any security which isn't enforced by the filesystem driver
>doesn't exist in a Unix environment;
>
What does this mean? I don't understand.
> in particular there is no security
>against root. Stupid tricks like remapping uid 0 are just that; stupid
>tricks without any real security value. You know this, of course.
>However, if you think the automounter doesn't have the privilege to
>access the remote server but the user does, then that's false security.
>
>
>
No, the security lies in the fact that the remote server knows the user
is privileged to access it. It's a side issue that the mount itself is
made using an automounter.
>Linux at this point has no ability to support actual user-mounted
>filesystems. There are things that could be done to remedy this, but it
>would require massive changes to every filesystem driver as well as to
>the VFS.
>
?? As part of our research into namespaces, we at Sun have gone through
and tried to identify the number of semantic changes required to achieve
user-privileged mounting, however we never saw the need to do anything
special at all in 'each filesystem driver'. The issue is one of a
permission model and should be out of scope for individual filesystems.
>Would it be desirable? Absolutely. However, it's partially
>the quagmire that got the HURD stuck for a very long time, even though
>they had the huge advantage of being able to run their filesystem
>drivers in a nonprivileged context.
>
>
>
Other systems such as plan 9 have done it though.. If anything is
keeping us from doing it, it's the traditional unix mount semantics and
the security models that have been built on top of them.
--
Mike Waychison
Sun Microsystems, Inc.
1 (650) 352-5299 voice
1 (416) 202-8336 voice
mailto: [email protected]
http://www.sun.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTICE: The opinions expressed in this email are held by me,
and may not represent the views of Sun Microsystems, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Mike Waychison wrote:
> H. Peter Anvin wrote:
>
>> My point is that it's what you get for having an automounter.
>>
>> We can't solve Sun's designed-in braindamage, unfortunately. This is
>> partially why I'd like people to consider the scope of what automounting
>> does; there are tons of policy issues not all of which are going to be
>> appropriate in all contexts. To some degree, if you have to have an
>> automounter you have already lost.
>>
>
> However, we can solve Linux's designed-in braindamage.
>
I was referring to the visibility of server-side mount points in NFS 2/3
and the fact that most of the uses of the automounter is to work around
this shortcoming. This is a protocol limitation.
(Don't get me started on stuff like "plus lines" in map, which breaks
the map paradigm completely. That's brokenness on a whole other level,
but which can be reasonably ignored.)
>> in particular there is no security
>> against root. Stupid tricks like remapping uid 0 are just that; stupid
>> tricks without any real security value. You know this, of course.
>> However, if you think the automounter doesn't have the privilege to
>> access the remote server but the user does, then that's false security.
>
> No, the security lies in the fact that the remote server knows the user
> is privileged to access it. It's a side issue that the mount itself is
> made using an automounter.
Again, it doesn't matter if the user passes credentials to an
automounter or to the kernel.
>> Linux at this point has no ability to support actual user-mounted
>> filesystems. There are things that could be done to remedy this, but it
>> would require massive changes to every filesystem driver as well as to
>> the VFS.
>
> ?? As part of our research into namespaces, we at Sun have gone through
> and tried to identify the number of semantic changes required to achieve
> user-privileged mounting, however we never saw the need to do anything
> special at all in 'each filesystem driver'. The issue is one of a
> permission model and should be out of scope for individual filesystems.
It's trivial to crash most filesystem drivers (or get to a security leak
level) by feeding them deliberately bad input. Robustness against
corruption in Linux has been with respect to likely data corruption much
more than deliberate attacks. It's a major effort; security-auditing
every filesystem driver.
-hpa
H. Peter Anvin wrote:
>Mike Waychison wrote:
>
>
>>H. Peter Anvin wrote:
>>
>>
>>
>>>My point is that it's what you get for having an automounter.
>>>
>>>We can't solve Sun's designed-in braindamage, unfortunately. This is
>>>partially why I'd like people to consider the scope of what automounting
>>>does; there are tons of policy issues not all of which are going to be
>>>appropriate in all contexts. To some degree, if you have to have an
>>>automounter you have already lost.
>>>
>>>
>>>
>>However, we can solve Linux's designed-in braindamage.
>>
>>
>>
>
>I was referring to the visibility of server-side mount points in NFS 2/3
>and the fact that most of the uses of the automounter is to work around
>this shortcoming. This is a protocol limitation.
>
>
>
It's just a different way of looking at it. NFS exports filesystems,
not namespaces. It's the server implementation that decides it should
try to map these exports to its local namespace. Indeed, this is what
exportfs and /etc/exports tries to do. Nobody said this mapping made
alot of sense.
>(Don't get me started on stuff like "plus lines" in map, which breaks
>the map paradigm completely. That's brokenness on a whole other level,
>but which can be reasonably ignored.)
>
>
>
Your on your own on that one. I don't see it as an issue as the
semantics are pretty well defined.
>It's trivial to crash most filesystem drivers (or get to a security leak
>level) by feeding them deliberately bad input. Robustness against
>corruption in Linux has been with respect to likely data corruption much
>more than deliberate attacks. It's a major effort; security-auditing
>every filesystem driver.
>
>
Ok. Thanks for clearing that up.
--
Mike Waychison
Sun Microsystems, Inc.
1 (650) 352-5299 voice
1 (416) 202-8336 voice
mailto: [email protected]
http://www.sun.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTICE: The opinions expressed in this email are held by me,
and may not represent the views of Sun Microsystems, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~