Tom,
Does this apply to sharing out to netgroups and IP ranges as well?
-Mark
-----Original Message----- From: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Haynes, Tom Sent: Tuesday, January 06, 2004 9:48 AM To: Jerry Cc: toasters@mathworks.com Subject: Re: exports
What happens if someone reuses the host name after a month?
Say you have an export: /vol/payroll -access=george:harry:arnold:fred,rw=harry:arnold:george,root=arnold:geor ge
And you retire arnold. You never change the export or there is a new admin who doesn't know to look at the export lists.
Several times since the old arnold was retired, "exportfs -a" was run. Warning messages were printed to the console about no arnold being available. We don't let arnold have rw or root permissions, but due to the nature of -access, we have to leave the string "arnold" in that list, meaning that the client arnold would still have read/only access.
Someone brings up a general purpose server on the network and being a huge fan of TV pigs, goes immediately for the available host name of arnold.
The new arnold is immediatley able to get read permissions on /vol/payroll and several salaries get shared.
A new volume gets created on the filer and someone reruns "exportfs -a". Now arnold is able to write as root to the payroll volume.
In retrospect, a warning would have been nicer, wild security example aside, but at the time we were trying to patch the exports code and not redesign it to a new specification.
We redesigned the exports code in 6.5 and as we no longer preload host IPs for -rw= and -root=, we do not detect that a host is no longer being resolved to IP. As a result, we do not throw away the entire export rule.
The flip side is that arnold can still run amuck through your payroll, so check your export lists when you retire a secure server name. ;>
Has anyone seen where exporting a filesystem after a reboot fails because exports has the name of a host that no longer exists?
My co-worker had this problem and support said this is by design. This proved to be problematic for us when we had a filer reboot and it failed to export some filesystems because some host had been removed a long time ago. Considering the reliability of the filer, it's reasonable that some hosts in the export list might disappear, I'd rather see this as a warning than something that breaks the filer's ability to serve volumes. After all, nothing a client does should break a server, general rule.
Jerry
Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus
Mark,
In pre-6.5 ONTAP, netgroups are special in the sense that they only appear in -access. We never pre-cache IP in the -access list. So, you won't see an export dropped because a name in the -access list can not be found in DNS.
If I understand your question, you are asking that if a netgroup or IP range is retired, they are never yanked from /etc/exports, and then someone else starts using them in an inadvertant manner? Then yes, as far as I know every Unix based system out there will suffer from the same problem of granting access to those boxes.
You have to remember that mountd, exportfs, share, etc are all reactive protocols. They do not proactively go out there and see if they can find all of the needed hosts. It can be prohibitive.
Consider an export of: /vol/slow -rw=10.0.0.0/8:foo
How often would you want to scan the all of the 10 subnet? Just on exportfs -a or every day or so?
The point of the scenario below should be to make sure you have proper security processes in place to remove clients from export lists when you either:
1) retire that client from the name servers, 2) change the client name, 3) loosen security on the client, i.e. from a secure server to a general login machine.
Thanks, Tom
By the way, I looked at all of the responses which came back about the feature of dropping the entire export if a name did not resolve and decided the feature was actually a bug. The proper procedure must be that we skip that name, report the lack of name resolution to the admin, and keep on loading the export.
For those of you interested in tracking that fix, it is covered in bug 111941.
Tom,
Does this apply to sharing out to netgroups and IP ranges as well?
-Mark
-----Original Message----- From: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Haynes, Tom Sent: Tuesday, January 06, 2004 9:48 AM To: Jerry Cc: toasters@mathworks.com Subject: Re: exports
What happens if someone reuses the host name after a month?
Say you have an export: /vol/payroll -access=george:harry:arnold:fred,rw=harry:arnold:george,root=arnold:geor ge
And you retire arnold. You never change the export or there is a new admin who doesn't know to look at the export lists.
Several times since the old arnold was retired, "exportfs -a" was run. Warning messages were printed to the console about no arnold being available. We don't let arnold have rw or root permissions, but due to the nature of -access, we have to leave the string "arnold" in that list, meaning that the client arnold would still have read/only access.
Someone brings up a general purpose server on the network and being a huge fan of TV pigs, goes immediately for the available host name of arnold.
The new arnold is immediatley able to get read permissions on /vol/payroll and several salaries get shared.
A new volume gets created on the filer and someone reruns "exportfs -a". Now arnold is able to write as root to the payroll volume.
In retrospect, a warning would have been nicer, wild security example aside, but at the time we were trying to patch the exports code and not redesign it to a new specification.
We redesigned the exports code in 6.5 and as we no longer preload host IPs for -rw= and -root=, we do not detect that a host is no longer being resolved to IP. As a result, we do not throw away the entire export rule.
The flip side is that arnold can still run amuck through your payroll, so check your export lists when you retire a secure server name. ;>
Has anyone seen where exporting a filesystem after a reboot fails because exports has the name of a host that no longer exists?
My co-worker had this problem and support said this is by design. This proved to be problematic for us when we had a filer reboot and it failed to export some filesystems because some host had been removed a long time ago. Considering the reliability of the filer, it's reasonable that some hosts in the export list might disappear, I'd rather see this as a warning than something that breaks the filer's ability to serve volumes. After all, nothing a client does should break a server, general rule.
Jerry
Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus
-- Tom Haynes, ex-cfb thomas@netapp.com
-
Haynes, Tom -
markallen＠micron.com