NFS Exporting a samba share-yjh777-ChinaUnix博客

10-02-2007, 03:00 PM

Hi,
I have an nfs export set up as follows in my /etc/exports:

/a spongebob(rw)

Which (surprisingly enough) the machine spongebob can mount OK..

The problem comes where I have some samba mounts on the server located
at /a/mounts/1, /a/mounts/2, /a/mounts/3, etc.. The machine spongebob
can't access anything from inside of the samba mounts.. It can see
that the directories 1, 2, and 3 exist, and can even cd into them. It
just doesn't see any of the files inside and can't open them.

I have been looking at permissions and all the mount points on the
server and they are all owned by the same owner as the rest of /a, so
it should be fine.

The server is running Mandrake 7.x (iirc) and the client is running
Solaris 9. The servers hosting the samba shares are all Windows
2000/XP machines.

10-02-2007, 03:00 PM

(Paul Richards) wrote in message news:...
> Hi,
> I have an nfs export set up as follows in my /etc/exports:
>
> /a spongebob(rw)
>
> Which (surprisingly enough) the machine spongebob can mount OK..

>
> The problem comes where I have some samba mounts on the server located
> at /a/mounts/1, /a/mounts/2, /a/mounts/3, etc.. The machine spongebob
> can't access anything from inside of the samba mounts.. It can see
> that the directories 1, 2, and 3 exist, and can even cd into them. It
> just doesn't see any of the files inside and can't open them.

NFS servers will typically not let clients cross a server's mount point.
Try exporting the samba mounts. This assumes the samba file system
will allow NFS exporting.

10-02-2007, 03:00 PM

Mike Eisler wrote:
> (Paul Richards) wrote in message
> news:...
>> Hi,
>> I have an nfs export set up as follows in my /etc/exports:
>>
>> /a spongebob(rw)
>>
>> Which (surprisingly enough) the machine spongebob can mount OK..

>>
>> The problem comes where I have some samba mounts on the server
>> located at /a/mounts/1, /a/mounts/2, /a/mounts/3, etc.. The machine
>> spongebob can't access anything from inside of the samba mounts..
>> It can see that the directories 1, 2, and 3 exist, and can even cd
>> into them. It just doesn't see any of the files inside and can't
>> open them.
>
> NFS servers will typically not let clients cross a server's mount
> point.

This is completely correct. There are a ton of reasons for this, but
allowing machine C to inherit permissions from machine B to access things on
machine A just breaks a lot of security and file locking paradigms.
Transitive directory mounting is just a big, big, big problem.

> Try exporting the samba mounts. This assumes the samba file system
> will allow NFS exporting.

Try the reverse. You can SMB export almost anything, including other SMB
mounts and including NFS mounts. Alternatively, set up the SMB mount to be
mounted somewhere else on machine B and C and use symbolic links inside /a
pointing to the other SMB mount point, which is a quite common way to do
things.

10-02-2007, 03:00 PM

"Nico Kadel-Garcia" wrote in message news:...
> Mike Eisler wrote:
> > (Paul Richards) wrote in message
> > news:...
> >> Hi,
> >> I have an nfs export set up as follows in my /etc/exports:
> >>
> >> /a spongebob(rw)
> >>
> >> Which (surprisingly enough) the machine spongebob can mount OK..

> >>
> >> The problem comes where I have some samba mounts on the server
> >> located at /a/mounts/1, /a/mounts/2, /a/mounts/3, etc.. The machine
> >> spongebob can't access anything from inside of the samba mounts..
> >> It can see that the directories 1, 2, and 3 exist, and can even cd
> >> into them. It just doesn't see any of the files inside and can't
> >> open them.
> >
> > NFS servers will typically not let clients cross a server's mount
> > point.
>
> This is completely correct. There are a ton of reasons for this, but
> allowing machine C to inherit permissions from machine B to access things on
> machine A just breaks a lot of security and file locking paradigms.
> Transitive directory mounting is just a big, big, big problem.

Sure but unless there's an "is_remote" interface that the NFS server
can use to query the file system being accessed, this is not the
reason
why NFS servers don't allow mount point crossing. The primary reason
they
don't is that NFS clients are suually implemented on POSIX compatible
systems, which expect a unique inode#/fsid# for each file. The NFS
client generates its own fsid for each NFS mount point. If the server
allowed mount point crossing, then unique inode#s could not be
generated,
which often produces operational problems on the client.

NFS servers typically can't export NFS mounts because of the way the
file handle is constructed; it turns out that attempting to do so
at minimum doubles the size of the NFS file handle, which is not
infinite in length.

> > Try exporting the samba mounts. This assumes the samba file system
> > will allow NFS exporting.
>
> Try the reverse. You can SMB export almost anything, including other SMB
^^^^^^^^^^^^^^^^^^
That only works if the NFS client also has an SMB client, which was
not
specified in the original post. If this were so, then there's be no
point in original question.

> mounts and including NFS mounts. Alternatively, set up the SMB mount to be
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
So to quote you: "allowing machine C to inherit permissions from
machine B to access things on machine A just breaks a lot of security
and file locking paradigms. Transitive directory mounting is just a
big, big, big problem."

Why is it, if NFS does it, it's a problem, but if an SMB server does
it, it
is not?

> mounted somewhere else on machine B and C and use symbolic links inside /a
> pointing to the other SMB mount point, which is a quite common way to do
> things.

10-02-2007, 03:00 PM

(Mike Eisler) wrote in message news:<36f0f19f.0407070450.511d1f0c@posting.google.com>...
> "Nico Kadel-Garcia" wrote in message news:...
> > Mike Eisler wrote:
> > > (Paul Richards) wrote in message
> > > news:...
> > >> Hi,
> > >> I have an nfs export set up as follows in my /etc/exports:
> > >>
> > >> /a spongebob(rw)
> > >>
> > >> Which (surprisingly enough) the machine spongebob can mount OK..

> > >>
> > >> The problem comes where I have some samba mounts on the server
> > >> located at /a/mounts/1, /a/mounts/2, /a/mounts/3, etc.. The machine
> > >> spongebob can't access anything from inside of the samba mounts..
> > >> It can see that the directories 1, 2, and 3 exist, and can even cd
> > >> into them. It just doesn't see any of the files inside and can't
> > >> open them.
> > >
> > > NFS servers will typically not let clients cross a server's mount
> > > point.
> >
> > This is completely correct. There are a ton of reasons for this, but
> > allowing machine C to inherit permissions from machine B to access things on
> > machine A just breaks a lot of security and file locking paradigms.
> > Transitive directory mounting is just a big, big, big problem.
>
> Sure but unless there's an "is_remote" interface that the NFS server
> can use to query the file system being accessed, this is not the
> reason
> why NFS servers don't allow mount point crossing. The primary reason
> they
> don't is that NFS clients are suually implemented on POSIX compatible
> systems, which expect a unique inode#/fsid# for each file. The NFS
> client generates its own fsid for each NFS mount point. If the server
> allowed mount point crossing, then unique inode#s could not be
> generated,
> which often produces operational problems on the client.
>
> NFS servers typically can't export NFS mounts because of the way the
> file handle is constructed; it turns out that attempting to do so
> at minimum doubles the size of the NFS file handle, which is not
> infinite in length.
>
> > > Try exporting the samba mounts. This assumes the samba file system
> > > will allow NFS exporting.
> >
> > Try the reverse. You can SMB export almost anything, including other SMB
> ^^^^^^^^^^^^^^^^^^
> That only works if the NFS client also has an SMB client, which was
> not
> specified in the original post. If this were so, then there's be no
> point in original question.

I am not totally sure that I understand why changing my /a mount to be
a samba share would fix things.. Would I really be able to navigate
into /a/mounts/1, etc..? How does samba get around the problem that
NFS has?

In this case the client machine (Solaris 9) does have a samba client
available. The only problem is that I'm not sure how well samba
handles the unix file permissions. Does anyone know if my system will
be happy having home directories mounted over samba?

>
> > mounts and including NFS mounts. Alternatively, set up the SMB mount to be
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> So to quote you: "allowing machine C to inherit permissions from
> machine B to access things on machine A just breaks a lot of security
> and file locking paradigms. Transitive directory mounting is just a
> big, big, big problem."
>
> Why is it, if NFS does it, it's a problem, but if an SMB server does
> it, it
> is not?
>
> > mounted somewhere else on machine B and C and use symbolic links inside /a
> > pointing to the other SMB mount point, which is a quite common way to do
> > things.

10-02-2007, 03:00 PM

"Mike Eisler" wrote in message
news:36f0f19f.0407070450.511d1f0c@posting.google.c om...

> > > Try exporting the samba mounts. This assumes the samba file system
> > > will allow NFS exporting.
> >
> > Try the reverse. You can SMB export almost anything, including other SMB
> ^^^^^^^^^^^^^^^^^^
> That only works if the NFS client also has an SMB client, which was
> not
> specified in the original post. If this were so, then there's be no
> point in original question.
>
> > mounts and including NFS mounts. Alternatively, set up the SMB mount to
be
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> So to quote you: "allowing machine C to inherit permissions from
> machine B to access things on machine A just breaks a lot of security
> and file locking paradigms. Transitive directory mounting is just a
> big, big, big problem."
>
> Why is it, if NFS does it, it's a problem, but if an SMB server does
> it, it
> is not?

That's a very good question. It's a potential problem with security and
file-locking craziness, which NFS handles by saying "You can't do that you
silly goose". But the file ownership, file permissions, and file locking of
SMB is far more handled, at least for Samba servers and ASU servers, by
programs in userspace, not by kernel fun and joy. You described some of the
kernel-level fun and joy for NFS in your bits that I snipped. So while the
security and file-locking issues exist, SMB servers like Samba just go ahead
and provide them anyway. Also, SMB is nowhere near so vulnerable to the
sorts of failures NFS experiences when either a client *or* a server loses
track of its partner, such as during an extended network interruption or
power failures, and refuses to let go of the old mount and require rebooting
of *both* machines, especially with having to go in by hand and remove
entries from the "rmtab" file. Add in a middle NFS server doing transitive
file mounting and you're asking for your head on a platter, carved up fine
and scatterd with onion rings.

But in places like the Windows world, you can't mount one directory inside
another, so you do avoid some of the potential delights.

> > mounted somewhere else on machine B and C and use symbolic links inside
/a
> > pointing to the other SMB mount point, which is a quite common way to do
> > things.

10-02-2007, 03:00 PM

"Paul Richards" wrote in message
news:a1138db3.0407071239.2379816a@posting.google.c om...

> I am not totally sure that I understand why changing my /a mount to be
> a samba share would fix things.. Would I really be able to navigate
> into /a/mounts/1, etc..? How does samba get around the problem that
> NFS has?
>
>
> In this case the client machine (Solaris 9) does have a samba client
> available. The only problem is that I'm not sure how well samba
> handles the unix file permissions. Does anyone know if my system will
> be happy having home directories mounted over samba?

I got it working just fine under SunOS 4.x years ago. If you're using Samba,
it should work fine unless Sun has done oddnesses to their OS since then.
Mind you, they may have done oddnesses to it. That's why I pointed out the
alternative of using symbolic links instead of mount points to point to
another location.

Creating a robust, flexible structure for mounting things appropriately
inside your network can be lots of fun to get right. And in fact,
personally, I'd use symbolic links to distinct mount points inside the first
mounted directory to make things work more flexibly and avoid running an
additional file server on the intermediate client.

10-02-2007, 03:00 PM

(Paul Richards) wrote in message news:...
> > > Try the reverse. You can SMB export almost anything, including other SMB
> > ^^^^^^^^^^^^^^^^^^
> > That only works if the NFS client also has an SMB client, which was
> > not
> > specified in the original post. If this were so, then there's be no
> > point in original question.
>
>
> I am not totally sure that I understand why changing my /a mount to be
> a samba share would fix things.. Would I really be able to navigate

Probablt because Samba servers are SMB servers engineered for
Windows clients, and Windows clients don't care about
POSIX issues.

> into /a/mounts/1, etc..? How does samba get around the problem that
> NFS has?
>
>
> In this case the client machine (Solaris 9) does have a samba client
> available. The only problem is that I'm not sure how well samba

An in-kernel SMB client? for Solari s9. I knew there
were couple for Linux. Wow, I guess there's no need for NFSv4
now. :-)

> handles the unix file permissions. Does anyone know if my system will
> be happy having home directories mounted over samba?
>

10-02-2007, 03:00 PM

Mike Eisler wrote:

>> In this case the client machine (Solaris 9) does have a samba client
>> available. The only problem is that I'm not sure how well samba
>
> An in-kernel SMB client? for Solari s9. I knew there
> were couple for Linux. Wow, I guess there's no need for NFSv4
> now. :-)

Especially because AFS is available for Solaris, Linux, Windows, and MacOS
X, allowing a far more secure authentication structure and robust file
access for remotely connected sites.

10-02-2007, 03:00 PM

"Nico Kadel-Garcia" wrote in message news:...
> Mike Eisler wrote:
>
> >> In this case the client machine (Solaris 9) does have a samba client
> >> available. The only problem is that I'm not sure how well samba
> >
> > An in-kernel SMB client? for Solari s9. I knew there
> > were couple for Linux. Wow, I guess there's no need for NFSv4
> > now. :-)
>
> Especially because AFS is available for Solaris, Linux, Windows, and MacOS
> X, allowing a far more secure authentication structure and robust file
> access for remotely connected sites.

Kerberos V5 authentication, integrity, and
privacy for NFS has been shipping since 1998.

10-02-2007, 03:00 PM

"Mike Eisler" wrote in message
news:36f0f19f.0407090925.4a44dabb@posting.google.c om...
> "Nico Kadel-Garcia" wrote in message
news:...
> > Mike Eisler wrote:
> >
> > >> In this case the client machine (Solaris 9) does have a samba client
> > >> available. The only problem is that I'm not sure how well samba
> > >
> > > An in-kernel SMB client? for Solari s9. I knew there
> > > were couple for Linux. Wow, I guess there's no need for NFSv4
> > > now. :-)
> >
> > Especially because AFS is available for Solaris, Linux, Windows, and
MacOS
> > X, allowing a far more secure authentication structure and robust file
> > access for remotely connected sites.
>
> Kerberos V5 authentication, integrity, and
> privacy for NFS has been shipping since 1998.

Friend, have you ever *tried* to integrate Kerberos into NFS in the wild?
It's..... pretty painful, at least the last couple of times *I* tried it.
And you missed the "robust" part. There is still no fix for the "if you lose
network connections of a hard-mounted NFS directory, you often need to
reboot both the server and the client to clean up the mess" problem. This
has been true for many years, and remains unchanged, especially since a lot
of NFS clients have built-in antique sources and lack these resources but
are expected to continue operating as modern servers.

OSF/1, anyone?

10-02-2007, 03:00 PM

"Nico Kadel-Garcia" wrote in message news:...
> "Mike Eisler" wrote in message
> news:36f0f19f.0407090925.4a44dabb@posting.google.c om...
> > "Nico Kadel-Garcia" wrote in message
> news:...
> > > Mike Eisler wrote:
> > >
> > > >> In this case the client machine (Solaris 9) does have a samba client
> > > >> available. The only problem is that I'm not sure how well samba
> > > >
> > > > An in-kernel SMB client? for Solari s9. I knew there
> > > > were couple for Linux. Wow, I guess there's no need for NFSv4
> > > > now. :-)
> > >
> > > Especially because AFS is available for Solaris, Linux, Windows, and
> MacOS
> > > X, allowing a far more secure authentication structure and robust file
> > > access for remotely connected sites.
> >
> > Kerberos V5 authentication, integrity, and
> > privacy for NFS has been shipping since 1998.
>
> Friend, have you ever *tried* to integrate Kerberos into NFS in the wild?

Yes. I've even shipped implementations of it.

ANyway, what do you mean by integrating Kerberos into NFS? Either
the NFS client and server support RFC 2203 or they don't. Only one
commerically supported UNIX client supports the RFC today, and
several servers.

> It's..... pretty painful, at least the last couple of times *I* tried it.

Do tell.

> And you missed the "robust" part. There is still no fix for the "if you lose
> network connections of a hard-mounted NFS directory, you often need to
> reboot both the server and the client to clean up the mess" problem. This

This is somethig I've never personally experienced, though I've tended
to confine myself to good clients. Indeed, in the early days of NFS,
my desktop ran completely diskless. In those days servers were less
reliable than clients, and hard mounts meant the desk top was frozen.
Then the server came back, the desktop came back to life, and
everything continued. No mess.

Since then, at least one client has added a forced unmount option.

> has been true for many years, and remains unchanged, especially since a lot
> of NFS clients have built-in antique sources and lack these resources but
> are expected to continue operating as modern servers.
>
> OSF/1, anyone?

OSF/1 is shipped by who now?

Anyway, I've nothing against AFS, except that people can't find
anyone to provide reliable commerical support for it now that IBM is
EOLing the commercial product. I wish OpenAFS all the best, but I fear
that just with the original CMU license, the
OpenAFs license will prevent it from taking hold. It was because of
the original license terms that AFS never made significant inroads, whereas,
NFS source code, for $25K a copy, and an optional $250K buy out of the
royalties, made it deal that no could refuse.

I find it interesting that people are looking running CIFS on UNIX/Linux
client and the file server.

10-02-2007, 03:00 PM

(Mike Eisler) wrote in message news:<36f0f19f.0407081629.6d92b402@posting.google.com>...
> (Paul Richards) wrote in message news:...
> > > > Try the reverse. You can SMB export almost anything, including other SMB
> > > ^^^^^^^^^^^^^^^^^^
> > > That only works if the NFS client also has an SMB client, which was
> > > not
> > > specified in the original post. If this were so, then there's be no
> > > point in original question.
> >
> >
> > I am not totally sure that I understand why changing my /a mount to be
> > a samba share would fix things.. Would I really be able to navigate
>
> Probablt because Samba servers are SMB servers engineered for
> Windows clients, and Windows clients don't care about
> POSIX issues.
>
> > into /a/mounts/1, etc..? How does samba get around the problem that
> > NFS has?
> >
> >
> > In this case the client machine (Solaris 9) does have a samba client
> > available. The only problem is that I'm not sure how well samba
>
> An in-kernel SMB client? for Solari s9. I knew there
> were couple for Linux. Wow, I guess there's no need for NFSv4
> now. :-)

Sorry actually.. I was wrong. The "Samba support" is has is only for
serving shares. It cannot mount shares onto the filesystem..

>
>
> > handles the unix file permissions. Does anyone know if my system will
> > be happy having home directories mounted over samba?
> >

10-02-2007, 03:00 PM

Mike Eisler wrote:
> "Nico Kadel-Garcia" wrote in message
> news:...
>> "Mike Eisler" wrote in message
>> news:36f0f19f.0407090925.4a44dabb@posting.google.c om...
>>> "Nico Kadel-Garcia" wrote in message
>> news:...
>>>> Mike Eisler wrote:
>>>>
>>>>>> In this case the client machine (Solaris 9) does have a samba
>>>>>> client available. The only problem is that I'm not sure how
>>>>>> well samba
>>>>>
>>>>> An in-kernel SMB client? for Solari s9. I knew there
>>>>> were couple for Linux. Wow, I guess there's no need for NFSv4
>>>>> now. :-)
>>>>
>>>> Especially because AFS is available for Solaris, Linux, Windows,
>>>> and
>> MacOS
>>>> X, allowing a far more secure authentication structure and robust
>>>> file access for remotely connected sites.
>>>
>>> Kerberos V5 authentication, integrity, and
>>> privacy for NFS has been shipping since 1998.
>>
>> Friend, have you ever *tried* to integrate Kerberos into NFS in the
>> wild?
>
> Yes. I've even shipped implementations of it.
>
> ANyway, what do you mean by integrating Kerberos into NFS? Either
> the NFS client and server support RFC 2203 or they don't. Only one
> commerically supported UNIX client supports the RFC today, and
> several servers.

Getting a Kerberized login system actually running can be extremely painful.
Most UNIX vendors do not keep open source tools like this up to date in
their distributions, and thus tend to lack feature sets or compatibility
with other UNIX or other OS distributions with even slightly different
versions. This problem occurs with both Kerberos and NFS releases across
multipls OS releases. If you take advantage of subtle configurations to make
things work the way you want (such as using an NIS domain name that does not
match your network's default domain name, or using hostnames that are not
fully qualified because of people's old software that uses "$HOSTNAME" =
"non-fully-qualified-hostname" sorts of statements, it quickly becomes a
nightmare. And Kerberos used to be pretty fascist about insisting that the
first hostname returned by various "gethostby*" functions actually match
both the local $HOSTNAME and be a fully-qualified-hostname.

In fact, at the time, you could not *compile* Kerberos on a system that did
not have a FQHN and have its FQHN first in the normally setup /etc/hosts
lines. It's not required anywhere in the RFC's, but there was a little
compilation step that recorded the hostname for logging purposes, which
broke on this and required the entire thing to be recompiled from scratch
due to unnecessary creation of a TIMESTAMP file at compile time, designed to
force complete recompilation from scratch instead of permitting partial
compilation and Makefile dependencies in the development phase.

Oh, yeah, I've been through this with Solaris, OSF/1, and maybe a dozen
Linux variants. The Linux folks, fortunately, tend to clean out this kind of
silliniess.

>> It's..... pretty painful, at least the last couple of times *I*
>> tried it.
>
> Do tell.

See above. Compiling a new set of NIS tools is even worse, and more
dangerous, because so much of it is women into libc in the Solaris world.
Recent versions of NIS may finally incorporate these features for Solaris
releases, but a lot of work places these days have a stack of old Solaris
2.6 and up systems. Integrating newer releases into those environments is
extremely difficult without turning off the more sophisticated
functionality, especially with Sun's long-standing practice of forcing OS
upgrades by only releasing the new OS's with new architectures. Backporting
the feature sets is..... also painful.

>> And you missed the "robust" part. There is still no fix for the "if
>> you lose network connections of a hard-mounted NFS directory, you
>> often need to reboot both the server and the client to clean up the
>> mess" problem. This
>
> This is somethig I've never personally experienced, though I've tended
> to confine myself to good clients. Indeed, in the early days of NFS,
> my desktop ran completely diskless. In those days servers were less
> reliable than clients, and hard mounts meant the desk top was frozen.
> Then the server came back, the desktop came back to life, and
> everything continued. No mess.

I've run into it fairly frequently, for years. It's not so bad if you use
auto-mounting, and if you don't have processes that auto-generate files on
the hard-mounted or auto-mounted system frequently, and if your disconnect
time is quite short.

But if someone accidentally unplugs a fiber for an hour on a system logging
utility that generates files on an NFS mount every minute, you're
definitively screwed on both ends, at least in my experience. It also gets
much worse if you have the old AMD based automount tools, rather than the
more recent autofs tools, that do the symbolic link whackiness to auto-mount
things under /tmp_mnt and create symbolic links to them.

> Since then, at least one client has added a forced unmount option.

I can believe that. It's also deadly in when a process is holding an NFS
mount point open: in both the Linux and Solaris world, "fuser -m mountpoint"
is your friend for finding these and putting a bullet through them.

>> has been true for many years, and remains unchanged, especially
>> since a lot of NFS clients have built-in antique sources and lack
>> these resources but are expected to continue operating as modern
>> servers.
>>
>> OSF/1, anyone?
>
> OSF/1 is shipped by who now?

It's not shipped, anymore. DEC's previous releases of it for the Alpha got
taken over by Compaq, then by HP, and HP has end-of-lifed it, partially
because Alpha support and development is also pretty dead since the Alpha
technology got bought out by Intel in the wake of DEC's collapse.

But it's still heavily used in a lot of server class file server
environments. AdvFS running on SMP 64-bit Alphas does quite well with
extremely large amounts of RAM and extremely large amounts of disk, in the
many Terabyte range.

> Anyway, I've nothing against AFS, except that people can't find
> anyone to provide reliable commerical support for it now that IBM is
> EOLing the commercial product. I wish OpenAFS all the best, but I fear

Ohhh, shoot. I liked AFS, and had good success with WAN deployments of
OpenAFS over Linux/Windows setups.

> that just with the original CMU license, the
> OpenAFs license will prevent it from taking hold. It was because of
> the original license terms that AFS never made significant inroads,
> whereas,
> NFS source code, for $25K a copy, and an optional $250K buy out of the
> royalties, made it deal that no could refuse.

Corporations couldn't refuse. Individuals poking around, however, could not
even get started.

> I find it interesting that people are looking running CIFS on
> UNIX/Linux
> client and the file server.

Yeah, I caught a presentation by Jeff Schiller of MIT on the fun and games
of CIFS authentication a few years back. It was pretty nifty, and as CPU
overhead has continued to drop in price, it's become a much more acceptable
overhead. But I've never had the opportunity or incentive to get it running.

SMB is looking better and better for UNIX/Linux access. The resistance to
failures of occasional disconnections, and its ubiquity in the Windows
world, coupled with the helpful "reset all files in this directory to be
owned by foo with permissions bar" that is trivial to set up in the Samba
configurations is getting more and more appealing.

10-02-2007, 03:00 PM

"Nico Kadel-Garcia" wrote in message news:...
> > ANyway, what do you mean by integrating Kerberos into NFS? Either
> > the NFS client and server support RFC 2203 or they don't. Only one
> > commerically supported UNIX client supports the RFC today, and
> > several servers.
>
> Getting a Kerberized login system actually running can be extremely painful.

Well there's much more to getting NFS to authenticate with Kerberos
that compiling a wad code from MIT or Heimdal. True end to
end authentication requires kernel support. Most people, unless
they operating systems implementors won't, and probably shouldn't
bother to take it on.

> Most UNIX vendors do not keep open source tools like this up to date in
> their distributions, and thus tend to lack feature sets or compatibility
> with other UNIX or other OS distributions with even slightly different
> versions. This problem occurs with both Kerberos and NFS releases across

Interoperability issues will always come up. This isn't
confined to Kerberos or NFS.

> multipls OS releases. If you take advantage of subtle configurations to make
> things work the way you want (such as using an NIS domain name that does not
> match your network's default domain name, or using hostnames that are not
> fully qualified because of people's old software that uses "$HOSTNAME" =
> "non-fully-qualified-hostname" sorts of statements, it quickly becomes a
> nightmare. And Kerberos used to be pretty fascist about insisting that the

Which is why the Solaris NFS/Kerberos V5 stack always canonicalizes
based on the FQDN returned by DNS.

have you actually used an NFS/Kerberos V5 stack, or are you
casting theory?

10-02-2007, 03:00 PM

Mike Eisler wrote:

>> multipls OS releases. If you take advantage of subtle configurations
>> to make things work the way you want (such as using an NIS domain
>> name that does not match your network's default domain name, or
>> using hostnames that are not fully qualified because of people's old
>> software that uses "$HOSTNAME" = "non-fully-qualified-hostname"
>> sorts of statements, it quickly becomes a nightmare. And Kerberos
>> used to be pretty fascist about insisting that the
>
> Which is why the Solaris NFS/Kerberos V5 stack always canonicalizes
> based on the FQDN returned by DNS.
>
> have you actually used an NFS/Kerberos V5 stack, or are you
> casting theory?

Harsh, harsh experience with older NFS/Kerberos implementations in very
heterogeneous configurations. Unless they've added something since then,
Kerberos uses the various "gethostby" functions in libc to try to determine
the canonical hostname, and actually uses the first entry returned as the
"canonical" name. And unfortunately, you can't just assert that "DNS gives
the canonical hostname". The various actual functions can and do give
multiple answers, depending on the system's pre-defined "HOSTNAME", the
contents of /etc/hosts, the NIS published "hosts" table, the contents of
/etc/resolv.conf to actually decide where to do the DNS lookup that you
mentioned, etc. DNS is in fact rarely configured to be their first source of
IP/HOSTNAME resolution, the first source is usually /etc/hosts. And the
function then typically returns all these names in order of how they were
resolved, namely from /etc/hosts first. This is why it's such fun to say
"OK, I've set hostname to be 'my.domain.com', but because I can get away
with it I put "127.0.0.2 my my.domain.com my.offsite-domain.com' in
/etc/hosts.

It's completely legal in DNS and these address functions to do this,
although it's usually considered a bad idea because such shortend hostnames
are not necessarily unique in even a modest sized network and can cause
fascinating, fascinating confusions for all involved. The main excuse to do
it is to simplify your life if you swap a machine from one DNS domain to
another frequently, and you want to be consistent about using a short alias
and non FQHN for your system-dependent software tools in both domains
without resetting your HOSTNAME. You can't safely just switch HOSTNAME at
whim: you'll break X-servers and X-clients running locally on your machine.
And ghods forbid you change HOSTNAME while you've got an NFS mount as client
or server! Changing HOSTNAME is usually accompanied by bringing the system
down to a single user mode to avoid exactly that sort of fun and games.

In a Kerberized environment, you probably shouldn't be hopping back and
forth between domains anyway, but I think you can see where it can get quite
complex to straighten out such joys and delights.

10-02-2007, 03:01 PM

"Nico Kadel-Garcia" wrote in message news:...
> Mike Eisler wrote:
>
> >> multipls OS releases. If you take advantage of subtle configurations
> >> to make things work the way you want (such as using an NIS domain
> >> name that does not match your network's default domain name, or
> >> using hostnames that are not fully qualified because of people's old
> >> software that uses "$HOSTNAME" = "non-fully-qualified-hostname"
> >> sorts of statements, it quickly becomes a nightmare. And Kerberos
> >> used to be pretty fascist about insisting that the
> >
> > Which is why the Solaris NFS/Kerberos V5 stack always canonicalizes
> > based on the FQDN returned by DNS.
> >
> > have you actually used an NFS/Kerberos V5 stack, or are you
> > casting theory?
>
> Harsh, harsh experience with older NFS/Kerberos implementations in very

Which NFS/Kerberos V5 stack have you used?

> heterogeneous configurations. Unless they've added something since then,
> Kerberos uses the various "gethostby" functions in libc to try to determine
> the canonical hostname, and actually uses the first entry returned as the
> "canonical" name. And unfortunately, you can't just assert that "DNS gives

Yes indeed, you are casting theory.

10-02-2007, 03:01 PM

Nico Kadel-Garcia wrote:

> Yeah, I caught a presentation by Jeff Schiller of MIT on the fun and games
> of CIFS authentication a few years back. It was pretty nifty, and as CPU
> overhead has continued to drop in price, it's become a much more acceptable
> overhead. But I've never had the opportunity or incentive to get it running.
>
> SMB is looking better and better for UNIX/Linux access. The resistance to
> failures of occasional disconnections, and its ubiquity in the Windows
> world, coupled with the helpful "reset all files in this directory to be
> owned by foo with permissions bar" that is trivial to set up in the Samba
> configurations is getting more and more appealing.

Funny you should say this, I've just finished adding the mknod call
into the Samba UNIX extensions that should allow the Linux CIFS client
to correctly mount peoples home directories case-sensitively and be
able to create unix domain socket files - thus allowing KDE etc to work
in a Samba-shared home directory.

I'm planning to give a talk on using SMB for UNIX to UNIX filesharing
(RFS reborn anyone ? :-) at both the CIFS and NFS conferences this year.

Jeremy.

10-02-2007, 03:01 PM

Mike Eisler wrote:
> "Nico Kadel-Garcia" wrote in message
> news:...
>> Mike Eisler wrote:
>>
>>>> multipls OS releases. If you take advantage of subtle
>>>> configurations to make things work the way you want (such as using
>>>> an NIS domain name that does not match your network's default
>>>> domain name, or using hostnames that are not fully qualified
>>>> because of people's old software that uses "$HOSTNAME" =
>>>> "non-fully-qualified-hostname" sorts of statements, it quickly
>>>> becomes a nightmare. And Kerberos used to be pretty fascist about
>>>> insisting that the
>>>
>>> Which is why the Solaris NFS/Kerberos V5 stack always canonicalizes
>>> based on the FQDN returned by DNS.
>>>
>>> have you actually used an NFS/Kerberos V5 stack, or are you
>>> casting theory?
>>
>> Harsh, harsh experience with older NFS/Kerberos implementations in
>> very
>
> Which NFS/Kerberos V5 stack have you used?

Like I said, it's been a while. This level of adventurous analysis was going
in with the latest MIT Kerberos release and Solaris 2.5 and SunOS 4.1.x. I
took another shot at it about 5 years ago, and had too many problems getting
it to interoperate well with the Windows systems, then took another shot at
it maybe 3 years ago and couldn't get the buy in to make the corporate wide
changes.

Like I said, been there, done that. If both have evolved since then, fine,
but most sites these days use FQHN as their $HOSTNAME, and as their default
entries in /etc/hosts just as a matter of best practices.

>> heterogeneous configurations. Unless they've added something since
>> then, Kerberos uses the various "gethostby" functions in libc to try
>> to determine the canonical hostname, and actually uses the first
>> entry returned as the "canonical" name. And unfortunately, you can't
>> just assert that "DNS gives
>
> Yes indeed, you are casting theory.

No, I actually read the damn code. Have they changed it since then? It was
particularly irritating with the "I insist on having an FQHN in order to log
what machine compiled this code, and I won't let you recompile it except
from scratch because I have fiendishly installed a timestamp in the Makefile
structure to force onbly complete recompilations, moo-ha-ha!"

Look, friend, don't call it "casting theory" when someone's actually tried
to get the systems to work together and run into the ussue.

10-02-2007, 03:01 PM

"Nico Kadel-Garcia" wrote in message news:<-IednYCpvp46qGjdRVn_iw@comcast.com>...
> > Which NFS/Kerberos V5 stack have you used?
>
> Like I said, it's been a while. This level of adventurous analysis was going
> in with the latest MIT Kerberos release and Solaris 2.5 and SunOS 4.1.x. I
> took another shot at it about 5 years ago, and had too many problems getting
> it to interoperate well with the Windows systems, then took another shot at
> it maybe 3 years ago and couldn't get the buy in to make the corporate wide
> changes.
[...]
> > Yes indeed, you are casting theory.
[...]
> Look, friend, don't call it "casting theory" when someone's actually tried
> to get the systems to work together and run into the ussue.

Adding end to end Kerberos V5 authenticaton requires modifying the
NFS client and server, i.e. kernel work.

5 years ago, the only systems that support NFS w/ Kerberos were Solaris
and a couple of Windows NFS clients. And the Solaris implementation
didn't have DNS issues you note (though admittedly, the MIT base
much of the code it used did. Sun fixed it. I know, because
I led the folks who wrote the code). And SunOS 4.1.x never had Kerberos
authentication it is NFS client or server. Etc.

So at best, we are talking about something different. At
worst, if you are claiming that 5 years ago you tried it,
and can't identify the one NFS server that had it, and
misidentified SunOS 4.1.x as having it, then you didn't try it.

NFS implementations that adhere to the RFCs noted
below have no inferiority complex when it comes to strong
authentication, privacy, and integrity.

-mre (co-author, RFC 2203, author RFC 2623, which
describe the protocols needed for adding Kerberos
V5 authentication to NFSv4).

LinkBacks (?) LinkBack to this Thread:
Posted By	For	Type	Date
		Refback	03-16-2008 03:50 PM

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
	unix	Samba	1	06-04-2008 12:00 AM
	unix	Samba	1	06-03-2008 11:50 PM
	unix	Samba	0	11-16-2007 11:20 AM
	unix	Samba	3	10-07-2007 12:39 PM
	unix	SMB	19	10-02-2007 07:01 PM