This is too funny... Almost sounds like Netapp is taking a Microsoft approach... Making it easier for the system administrators... LOL!
Paul Brubaker, Jr. RIDS - Intel System Support AT&T Wireless Services * office phone: 717-526-5011 * cell phone: 717-578-2254 * e-mail: paul.brubaker@attws.com
-----Original Message----- From: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Jim Harm Sent: Tuesday, August 17, 2004 11:35 AM To: toasters@mathworks.com Subject: Re: Automatic NFS export on vol create
I don't like it either. In addition, when you do a volume name change, the OS will quietly change the exports file to what it thinks you'd like to have there. I feel it's rude to make those changes to MY export file without letting me know. NetApp says they are making it easier for system administration for less experienced owners.
At 10:06 AM -0500 8/17/04, Chris Blackmor wrote:
I agree with you Chris. I don't think automatic exports of any kind are a good idea. I would rather err on the side of not giving access than opening it up to the world without my knowledge. I know soon enough if I have forgotten to export something but I *WON'T* know soon enough if the system has *helped* me out.
What say ye NA-Folks? C-
On Tue, Aug 17, 2004 at 03:47:15PM +0100, Chris Thompson wrote:
I have been caught out by one aspect of the changed NFS export implementation in ONTAP 6.5.x (specifically, 6.5.1R1P6), that might have had serious security implications.
When a volume is created, say /vol/test, it is now autmatically NFS exported with a rule
/vol/test -rw,nosuid
i.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.
Having noticed that at the time, I did
exportfs -io rw=[a-testing-host],root=[a-testing-host] /vol/test
and continued with my tests (which involved restoring bits of other filing systems into /vol/test).
What I hadn't realised was that the original "vol create test" had not only exported the volume, it had added a line to /etc/exports. So
the next time the filer was rebooted, the unrestricted export came back... which, of course, I didn't notice for some time.
Has anyone else been caught out like this? Does anyone else think that these automatic NFS exports shouldn't be happening at all?
-- 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.
--
-------
- Chris Blackmor _______ | If I keep doing what
I am *
- Advanced Micro Devices ____ | | doing
*
- Phone: (512) 602-1608 /| | | | I'll keep getting what
I am *
- Fax: (512) 602-5155 | |___| | | getting
*
- Email: chris.blackmor@amd.com |____/ | | Author
Unknown*
-------
My comments are mine, and mine alone.
*
... simply following the previous post about security issue "wishes":
I would also apreciate in having a consistent way in starting and stopping the services on the filers. We have:
nfs on / off snapmirror on / off fcp start / stop iscsi start / stop cifs restart / terminate options snapvault.enable on / off ...
This is just a short excerpt, that just came in my head. I think there are appr. two more different ways in turning services on/off ... Oh, yes. I think, there is at least also true and false ...
Some services have to be started by entering the name of the service "SERVICE on / off", sometimes I have use the "options SERVICENAME.enable on / off"
nfs is a server, iscsi is a server, cifs is a server. Why does NetApp need three different ways of starting/stopping them?
Why don't we get a simple on / off for all these services? e.g. cifs on / off iscsi on / off
Or why don't we allow (for compatibility) both ways as synonyms: (on = start / off = stop)?
Believing in a better (easier) world to come... Yours sincerly Dirk Schmiedt