Well, I think that's about my personal best for a toasters posting stirring things up! :-)
First, a small correction. I wrote:
When a volume is created, say /vol/test, it is now autmatically NFS exported with a rule
/vol/test -rw,nosuidi.e. read-write to the world. As a volume starts off with just a root-owned top-level directory, and there's no "root=" clause, this isn't _exactly_ a security exposure staight away, but of course it becomes one as soon as more interesting data is installed there.
Actually, the export options used are "-rw,root=[the admin.hosts option]". It just so happens that I have admin.hosts set to the empty list on this filer (originally done for tidyness: what hosts I might want to be admin hosts changes all the time - it didn't occur to me that it would [partially] save me in the current context).
Picking some points pseudo-randomly from the thread ...
Tom Haynes thomas@netapp.com wrote:
One thing to be remembered in all of this discussion is that the export changes were driven by customer requests. So, what one customer may not like, some other customer *had* to have in the code.
I dispute that anyone "*had*" to have this change. The situation is actually that in order to make things *easier* for a certain class of users using filers in very stereotyped ways, you have introduced potentially quite serious security exposures for the rest of us.
We were automatically creating default exports for the root volume. This allowed an admin to start editing files as soon as a NFS license was given to the filer.
We expanded this capability to include all volumes.
I dispute that the cases are at all analogous. The original root volume NFS export was done by the "setup" command (I haven't checked whether you've changed that in 6.5.x as well) as part of bootstrapping a filer into existence, and of course one expected to go over the eventual configuration with a fine toothcomb. Creating a new volume on an existing filer just isn't a comparable activity.
Bruce Arden arden@nortelnetworks.com wrote:
Does "vol create" create a CIFS shares as well?
No it doesn't, and that is a very pertinent point. "setup" assumed that NFS would be used for (initial) administration because ... well, because that's all there was in the early days of NetApp. A rethink of "setup" to help non-NFS-capable sysadmins might have been a more pertinent objective.
Mike Sphar mike.sphar@Remedy.COM wrote:
Speaking purely for myself, as a long-time Sysadmin, the fact that so much of Netapp's config is stored in text files was a *big* advantage to me.
I couldn't agree more ...
John Clear jclear@ati.com wrote:
Flat text files are good. If NetApp wants to make everything into a database, at least have an option to populate the database from a text file. Having `exportfs -a` read /etc/exports and create /etc/exports.db is fine, but I want to be able to edit a text file.
We keep quotas, exports and a few other of the config files under RCS on all our filers, so any automatic 'helpful' changes will be lost at the next check-out.
In fact I knew that I "ought to do something" about /etc/exports maintenance after the 6.5.x upgrade --- I just didn't realise it was so urgent!
Like John, I have always kept (the masters for) config files on filers under a change control system. Then in 5.3.4 the registry replaced the options settings in /etc/rc. I made do with a crontab that picks the options out of /etc/registry and compares them with a what-they-should-be file under change control and warns me of any differences. Now it looks as though I will need to do something similar for /etc/exports, but whereas many unexpected options settings are benign, that's much less likely to be true for unexpected NFS exports.
Chris Thompson University of Cambridge Computing Service, Email: cet1@ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QH, Phone: +44 1223 334715 United Kingdom.