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?
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,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.
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.
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,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.
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. *
I'll put myself in here, it seems like as good a point as any. And I'll forwarn you that I am the one who coded all of the changes in the way OnTap handles exports.
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.
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. One of the driving factors in our software design is Simplicity - we call the filer an appliance because of that goal.
By making automatic export changes, we remove some of the administrative burden. The cost for doing so is that the default actions may not be what the power users exactly want to do. (And an expectation is that a power admin will check the exports file 99% of the time. It is that other 1% of the time, especially with vol renames and a reboot, that cause them to submit RFEs for automatic editing.)
The main factors driving automatic editing of the /etc/exports file are: vol create vol destroy vol rename
In all 3 cases, we are changing the name of a volume. The nasty cases are where we combine the commands:
vol create payroll vol create scratch
exportfs -p rw=secure_hosts /vol/payroll exportfs -p rw,anon=0 /vol/scratch
fill up the payroll volume with critical data
vol offline scratch vol destroy scratch vol rename payroll scratch
Without automatic editing, anyone can now mount up filer:/vol/scratch and get access to the payroll data.
It is a contrived example, but it does show the types of concerns we are trying to address.
When a volume is renamed, the exports need to be changed to have the new volume name. All it takes is one time to forget to do this and a reboot of the filer, then you have ESTALE going to your applications. When a volume is deleted, the exports should be deleted from the exports file. If not, you continue to get error messages every time the exportfs -a command is run - which includes all reboots.
Some notes:
1) The automatic export creation: If you have an admin host defined, as per the setup command, then the automatic export creation is to that admin host: /vol/volX -rw,root=ADMIN,nosuid Else it is as Chris described: /vol/volX -rw,nosuid
2) If you want a command line export to be persistent, use the new, as of 6.5.1, flag -p:
exportfs -p rw=[a-testing-host],root=[a-testing-host] /vol/test
This command will add the export to /etc/exports.
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,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.
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. *
-- }}}===============>> LLNL James E. Harm (Jim); jharm@llnl.gov System Administrator, ICCD Clusters (925) 422-4018 Page: 423-7705x57152
Haynes, Tom wrote:
I'll put myself in here, it seems like as good a point as any. And I'll forwarn you that I am the one who coded all of the changes in the way OnTap handles exports.
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.
So why not an "option auto_update_exports off" ???
Then, we can *all* have it "our way".
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. One of the driving factors in our software design is Simplicity - we call the filer an appliance because of that goal.
By making automatic export changes, we remove some of the administrative burden. The cost for doing so is that the default actions may not be what the power users exactly want to do. (And an expectation is that a power admin will check the exports file 99% of the time. It is that other 1% of the time, especially with vol renames and a reboot, that cause them to submit RFEs for automatic editing.)
The main factors driving automatic editing of the /etc/exports file are: vol create vol destroy vol rename
In all 3 cases, we are changing the name of a volume. The nasty cases are where we combine the commands:
vol create payroll vol create scratch exportfs -p rw=secure_hosts /vol/payroll exportfs -p rw,anon=0 /vol/scratch fill up the payroll volume with critical data vol offline scratch vol destroy scratch vol rename payroll scratchWithout automatic editing, anyone can now mount up filer:/vol/scratch and get access to the payroll data.
It is a contrived example, but it does show the types of concerns we are trying to address.
When a volume is renamed, the exports need to be changed to have the new volume name. All it takes is one time to forget to do this and a reboot of the filer, then you have ESTALE going to your applications. When a volume is deleted, the exports should be deleted from the exports file. If not, you continue to get error messages every time the exportfs -a command is run - which includes all reboots.
Some notes:
The automatic export creation: If you have an admin host defined, as per the setup command, then the automatic export creation is to that admin host: /vol/volX -rw,root=ADMIN,nosuid Else it is as Chris described: /vol/volX -rw,nosuid
If you want a command line export to be persistent, use the new,
as of 6.5.1, flag -p:
exportfs -p rw=[a-testing-host],root=[a-testing-host] /vol/test
This command will add the export to /etc/exports.
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. *
-- }}}===============>> LLNL James E. Harm (Jim); jharm@llnl.gov System Administrator, ICCD Clusters (925) 422-4018 Page: 423-7705x57152
I am with Matt on this one. If you want it to default as "on" that is fine. Then those of us who want to do everything ourselves are happy and those that want a little more help are happy too.
I appreciate NA trying to help but really... this goes a little too far. C-
On Tue, Aug 17, 2004 at 01:39:43PM -0400, Matt Phelps wrote:
Haynes, Tom wrote:
I'll put myself in here, it seems like as good a point as any. And I'll forwarn you that I am the one who coded all of the changes in the way OnTap handles exports.
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.
So why not an "option auto_update_exports off" ???
Then, we can *all* have it "our way".
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. One of the driving factors in our software design is Simplicity - we call the filer an appliance because of that goal.
By making automatic export changes, we remove some of the administrative burden. The cost for doing so is that the default actions may not be what the power users exactly want to do. (And an expectation is that a power admin will check the exports file 99% of the time. It is that other 1% of the time, especially with vol renames and a reboot, that cause them to submit RFEs for automatic editing.)
The main factors driving automatic editing of the /etc/exports file are: vol create vol destroy vol rename
In all 3 cases, we are changing the name of a volume. The nasty cases are where we combine the commands:
vol create payroll vol create scratch exportfs -p rw=secure_hosts /vol/payroll exportfs -p rw,anon=0 /vol/scratch fill up the payroll volume with critical data vol offline scratch vol destroy scratch vol rename payroll scratchWithout automatic editing, anyone can now mount up filer:/vol/scratch and get access to the payroll data.
It is a contrived example, but it does show the types of concerns we are trying to address.
When a volume is renamed, the exports need to be changed to have the new volume name. All it takes is one time to forget to do this and a reboot of the filer, then you have ESTALE going to your applications. When a volume is deleted, the exports should be deleted from the exports file. If not, you continue to get error messages every time the exportfs -a command is run - which includes all reboots.
Some notes:
- The automatic export creation:
If you have an admin host defined, as per the setup command, then the automatic export creation is to that admin host: /vol/volX -rw,root=ADMIN,nosuid Else it is as Chris described: /vol/volX -rw,nosuid
- If you want a command line export to be persistent, use the new,
as of 6.5.1, flag -p:
exportfs -p rw=[a-testing-host],root=[a-testing-host] /vol/test
This command will add the export to /etc/exports.
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.
-- }}}===============>> LLNL James E. Harm (Jim); jharm@llnl.gov System Administrator, ICCD Clusters (925) 422-4018 Page: 423-7705x57152
-- Matt Phelps System Administrator, Computation Facility Harvard - Smithsonian Center for Astrophysics mphelps@cfa.harvard.edu, http://cfa-www.harvard.edu
"What say we?" ... I'm glad you asked. Don't just leave an option to turn it off for new volumes. Give us an option to turn it OFF. Sometimes we rename a volume for REASON other than just renaming. It's function changes and it's clients change not just the name.
You did something stupid; didn't even tell your own people about it. It took days for them to realize(when I showed them examples) that this was screwing up their efforts to standardize a procedure to migrate data from one volume to another.
Option Screw-up.exports NO
At 12:58 PM -0500 8/17/04, Chris Blackmor wrote:
I am with Matt on this one. If you want it to default as "on" that is fine. Then those of us who want to do everything ourselves are happy and those that want a little more help are happy too.
I appreciate NA trying to help but really... this goes a little too far. C-
On Tue, Aug 17, 2004 at 01:39:43PM -0400, Matt Phelps wrote:
Haynes, Tom wrote:
I'll put myself in here, it seems like as good a point as any. And I'll forwarn you that I am the one who coded all of the changes in the way OnTap handles exports.
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.
So why not an "option auto_update_exports off" ???
Then, we can *all* have it "our way".
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. One of the driving factors in our software design is Simplicity - we call the filer an appliance because of that goal.
By making automatic export changes, we remove some of the administrative burden. The cost for doing so is that the default actions may not be what the power users exactly want to do. (And an expectation is that a power admin will check the exports file 99% of the time. It is that other 1% of the time, especially with vol renames and a reboot, that cause them to submit RFEs for automatic editing.)
The main factors driving automatic editing of the /etc/exports file are: vol create vol destroy vol rename
In all 3 cases, we are changing the name of a volume. The nasty cases are where we combine the commands:
vol create payroll vol create scratch exportfs -p rw=secure_hosts /vol/payroll exportfs -p rw,anon=0 /vol/scratch fill up the payroll volume with critical data vol offline scratch vol destroy scratch vol rename payroll scratchWithout automatic editing, anyone can now mount up filer:/vol/scratch and get access to the payroll data.
It is a contrived example, but it does show the types of concerns we are trying to address.
When a volume is renamed, the exports need to be changed to have the new volume name. All it takes is one time to forget to do this and a reboot of the filer, then you have ESTALE going to your applications. When a volume is deleted, the exports should be deleted from the exports file. If not, you continue to get error messages every time the exportfs -a command is run - which includes all reboots.
Some notes:
- The automatic export creation:
If you have an admin host defined, as per the setup command, then the automatic export creation is to that admin host: /vol/volX -rw,root=ADMIN,nosuid Else it is as Chris described: /vol/volX -rw,nosuid
- If you want a command line export to be persistent, use the new,
as of 6.5.1, flag -p:
exportfs -p rw=[a-testing-host],root=[a-testing-host] /vol/test
This command will add the export to /etc/exports.
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.
-- }}}===============>> LLNL James E. Harm (Jim); jharm@llnl.gov System Administrator, ICCD Clusters (925) 422-4018 Page: 423-7705x57152
-- Matt Phelps System Administrator, Computation Facility Harvard - Smithsonian Center for Astrophysics mphelps@cfa.harvard.edu, http://cfa-www.harvard.edu
--
- 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. *
Matt Phelps wrote:
By making automatic export changes, we remove some of the administrative burden. The cost for doing so is that the default actions may not be what the power users exactly want to do. (And an expectation is that a power admin will check the exports file 99% of the time. It is that other 1% of the time, especially with vol renames and a reboot, that cause them to submit RFEs for automatic editing.)
what a wonderfull world... well, your arguments are persuasive
but
* ABOUT UPGRADES here, i speak for running Filers that are experiencing an Ontap Upgrade the more the black box change, indeed because of * " ' ` improvement ` ' " * the harder it becomes to administer, you always have to track down every change that could occur and pass lots of time to learn new way of doing the same thing - i could speak about options ip.sack.enable passed to on by default which cause enormous damages - i could speak about "vol snapmirror" commands that turn into new "snapmirror" set of command which make lost time and disapointed admins
i don't agree with your 99% for me, perhaps 99% of newbie netapp would appreciate the new feature but 99% of proven netapp admins won't appreciate it
each Ontapp upgrade had became a real challenge nowday (this was a formality before - 537 and some 6)
* ABOUT DOCUMENT NEW FEATURES you could tell me that i am saying something like : " i want no enhancement " " i want only bug correction " for sure i would be wrong because there is a right balance to aim
for me the balance is not respected when improvements occurs w/ out notification or too hard to track (or not enought clear when the improvment has important impact) i think netapp in general - you also i guess - did a good work in documenting new commands in manual and displaying messages at the filer boot, in /etc/messages explaining what had changed I think it is good but not enought
I would appreciate that every options which are new in the new release is displayed at the boot and can be understand with a little explanation message, and also a link to a manpage or any documentation and remember that the worst in a new command implementation is to "silently" change its behavior w/out noticing the user i understand it can be in a way, heavy to manage for you, but it is crucial for some admins (exports not exported after a reboot, snapmirror not running/resyncing after an upgrade w/out a warning, ...)
* ABOUT AUTOMATIZATION - admin does love the way the Filer automatically manage lots of thing (like disks, raid groups, vol add vol0 N, hot-plug/automatic jukebox detection, /etc/passwd automatic creation with notification of it) netapp add an abstract level on top of the uggly dirty hardware/repetitive stuff - i am sure numerous admin won't like at all automatic access to their data w/ out notification like permit nobody access to the root of a volume. access to data is not an abstract layer but is directly part of its security policy
* DON'T READ BELLOW i don't like windoz when windoz crash, you have to wait for the next service pack i thaught I was good at word 6. when i touch to word 2003, i was unable to work with, too much automatic stuff, i was unable to disable it the car i like to drive has a manual gear box
htc
[I must admit to not having had a chance to use 6.5 (or even 6.4)]
Does "vol create" create a CIFS shares as well? Does "vol rename" change all references to the volume - CIFS, qtrees, quotas, registry,...? Does "qtree create" work in the same way as "vol create"? If the answer to any of these is no, then the vol command shouldn't be doing any of this.
I think the automatic editing for the root volume used to be necessary because there was no other way of changing the exports file. But now with "exportfs -p" there is a way. So the feature could be removed (but add a warning message about the change of behaviour).
I don't agree with adding an option. If we must have the vol command changing the exports file, it should be controlled by a switch on the vol command. An option will cause great confusion where you do a change on a machine that has an unexpected option setting.
I think NetApp needs to resist customer/sales pressure to do things like this. I feel that filers are becoming like Veritas based systems, becoming too complex to manage. And perversely "simplifying" features like this are making it worse.
- Bruce
Matt Phelps wrote:
Haynes, Tom wrote:
I'll put myself in here, it seems like as good a point as any. And I'll forwarn you that I am the one who coded all of the changes in the way OnTap handles exports.
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.
So why not an "option auto_update_exports off" ???
Then, we can *all* have it "our way".
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. One of the driving factors in our software design is Simplicity - we call the filer an appliance because of that goal.
By making automatic export changes, we remove some of the administrative burden. The cost for doing so is that the default actions may not be what the power users exactly want to do. (And an expectation is that a power admin will check the exports file 99% of the time. It is that other 1% of the time, especially with vol renames and a reboot, that cause them to submit RFEs for automatic editing.)
The main factors driving automatic editing of the /etc/exports file are: vol create vol destroy vol rename
In all 3 cases, we are changing the name of a volume. The nasty cases are where we combine the commands:
vol create payroll vol create scratch exportfs -p rw=secure_hosts /vol/payroll exportfs -p rw,anon=0 /vol/scratch fill up the payroll volume with critical data vol offline scratch vol destroy scratch vol rename payroll scratchWithout automatic editing, anyone can now mount up filer:/vol/scratch and get access to the payroll data.
It is a contrived example, but it does show the types of concerns we are trying to address.
When a volume is renamed, the exports need to be changed to have the new volume name. All it takes is one time to forget to do this and a reboot of the filer, then you have ESTALE going to your applications. When a volume is deleted, the exports should be deleted from the exports file. If not, you continue to get error messages every time the exportfs -a command is run - which includes all reboots.
Some notes:
The automatic export creation: If you have an admin host defined, as per the setup command, then the automatic export creation is to that admin host: /vol/volX -rw,root=ADMIN,nosuid Else it is as Chris described: /vol/volX -rw,nosuid
If you want a command line export to be persistent, use the new,
as of 6.5.1, flag -p:
exportfs -p rw=[a-testing-host],root=[a-testing-host] /vol/test
This command will add the export to /etc/exports.
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 minealone. *
-- }}}===============>> LLNL James E. Harm (Jim); jharm@llnl.gov System Administrator, ICCD Clusters (925) 422-4018 Page: 423-7705x57152
On Wed, 18 Aug 2004, Bruce Arden wrote:
[I must admit to not having had a chance to use 6.5 (or even 6.4)]
So, how many people upon first login to 6.5x immediately typed the root password at the "login:" prompt? Whoops. Good thing the only person standing over my shoulder was another Unix admin as I reflexively started typing the password, in the clear, into the serial console log, after the 6.5.1 upgrade... a minor change in behavior (after 8 years of waiting for just the "Password" prompt), but one that I hadn't read about in the release notes and it could me totally by surprise.
I think the automatic editing for the root volume used to be necessary because there was no other way of changing the exports file. But now with "exportfs -p" there is a way. So the feature could be removed (but add a warning message about the change of behaviour).
I have to agree with this. One of the best features of ONTAP is that it just generally Does The Right Thing, but lately I'm guessing NetApp has been selling more filers into Windows shops, because stuff like the "registry" gunk has been creeping into the OS; I guess /etc/rc was just too old fashioned and Unixy. But seriously, an AUTOEXEC.BAT in etc/boot? That hurts.
Anyway, I just did an upgrade over the weekend without a clue that /vol/vol0/etc/exports was being tweaked - this thread was quite a shock.
vol create new ndmpcopy /vol/vol0 /vol/new vol rename vol0 old_vol0 vol rename new vol0 ...
Uh, whoops, now I've got this "/vol/new" export at the end of the file? Hmmm. Harmless, in this case, because at reboot there was no volume named "new" so it wasn't exported... still, this was another little surprise that could have had more serious consequences, and as another long-time Unix/ONTAP hacker I have to lobby against the dumbing down of ONTAP. Any sysadmin qualified to run the box can learn it in an hour or less; filers don't need to be much simpler than they are now. What's next? "Hey, Boeing, this 747 is too hard to fly, make it easier so we can use cheaper pilots."
Cringe.
-- Chris
Is it a dumbing down or an automation of common steps? I know when I designed and coded the automatic writing of the /etc/exports, my goal was to remove some repetitive and manual steps.
You have to remember that is what programming is all about: 1) finding common blocks of functionality and wrapping them in a function.
2) reducing the human interaction.
Some of the posters on this thread make it sound like this was a conspiracy.
If we had been a brand new company and we came out with a product which kept the exports information in a database instead of a flat file, would you have been this upset? Or would you have enjoyed the experience?
I've been of the flat file bent myself for a long time. Now that I have to maintain the exports file, I'm leaning towards a database for it. There is just too much ambiguity in parsing entries in the host lists - well formed fields, like *shudder* XML, make too much sense.
Anyway, there is no global plan to dumb down the product - just local designs to reduce problems found in customer escalations.
On Wed, 18 Aug 2004, Bruce Arden wrote:
Uh, whoops, now I've got this "/vol/new" export at the end of the file? Hmmm. Harmless, in this case, because at reboot there was no volume named "new" so it wasn't exported... still, this was another little surprise that could have had more serious consequences, and as another long-time Unix/ONTAP hacker I have to lobby against the dumbing down of ONTAP. Any sysadmin qualified to run the box can learn it in an hour or less; filers don't need to be much simpler than they are now. What's next? "Hey, Boeing, this 747 is too hard to fly, make it easier so we can use cheaper pilots."
Cringe.
-- Chris
Is it a dumbing down or an automation of common steps?
I agree. I think it is automation. But, maybe i dont want it.
How about -UpdateExportsFile or a -DontUpdateExportsFile to go along with vol create
If you are going to "automate" something, make sure you give people a way out of it. Your idea of automation might interfere with someone else's idea of control.
You have to remember that is what programming is all about:
- finding common blocks of functionality and wrapping them in a function.
- reducing the human interaction.
hmm. agreed...sorta.
The idea of programming is to "solve a problem". From the reaction on this list, looks like the automation created more problems than solved.
If i see more emails which say "thanks for automation the vol creation tom", i will be forced to think otherwise.
So, instead, lets solve old RFE's like ACL's for nfs first.
On Wed, 18 Aug 2004, Haynes, Tom wrote:
Is it a dumbing down or an automation of common steps? I know when I designed and coded the automatic writing of the /etc/exports, my goal was to remove some repetitive and manual steps.
First off, it's great that "toasters" is a list where implementers and other NetApp personnel can interact directly with customers. :-)
Secondly, it wasn't my intention to impune your motives or programming skills; it's more that this was a very unexpected change, and in watching ONTAP evolve since its very earliest days, I've been accustomed to new releases adhering to the "principle of least surprise". I scoured the release notes for 6.5.x when upgrading my last filer from 6.3.x, and carefully reviewed the parts about changes in the /etc/exports file - but I swear I can't remember seeing anything about the "vol" commands going in and changing the file...
Some of the posters on this thread make it sound like this was a conspiracy.
Heh heh.
[snip]
I've been of the flat file bent myself for a long time. Now that I have to maintain the exports file, I'm leaning towards a database for it. There is just too much ambiguity in parsing entries in the host lists - well formed fields, like *shudder* XML, make too much sense.
That's been a general argument in the Unix world for a long time - too many different flat files, too many different formats - but overcoming that interia has proven very difficult. I guess I'd suggest that if you stick with the flat file, then don't mess with the flat file; if you use the database format instead, then make it _clear_ that the database replaces or overrides the text file.
Kinda like moving more and more things out of /etc/rc into "persistent options" - as an old school Unix guy I still prefer to see and manage how things start up, and it was a little discouraging to have more and more things pulled out - we're almost at the point where /etc/rc ought to just be removed entirely (and I assume that's the development trajectory?) since it does so little. That's just one less mysterious text file for Windows admins to worry about - and one more adjustment for the (dwindling?) base of Unix guys to make.
Anyway, there is no global plan to dumb down the product - just local designs to reduce problems found in customer escalations.
Well, forgive an old cranky geek like me, but I still like to get under the hood, learn about and understand the product and its complexity, and be able to do the tuning and tweaking necessary to get the most out of the machine. It's _great_ that filers are so easy to set up and use, and I'm all for making improvements where needed. But I get concerned when "ease of use" features encroach upon or conflict with the already established ways of doing things that, in my opinion, don't need fixing.
-- Chris Unix snob and 8-year ONTAP admin :-)
User-friendliness aside -- automatically exporting created volumes read/write to the world is a horrible idea from a security perspective. Operations should always 'fail safe' from a security perspective. Things should not be enabled, exported, etc without a deliberate action on my part.
Thankfully I caught this because I'm monitoring critical files like this for unauthorized changes.
If you want to make things more user-friendly, enable a 'help.verbose' by default and print out friendly reminders after a vol create like "You will need to export your volume before clients can access it over the network", or something like that.
I'd hate to see OnTap get more user-friendly at the expense of doing the Right Thing. Besides, that's what the GUI is for.
My $0.02
On Wed, 18 Aug 2004, Haynes, Tom wrote:
Is it a dumbing down or an automation of common steps? I know when I designed and coded the automatic writing of the /etc/exports, my goal was to remove some repetitive and manual steps.
You have to remember that is what programming is all about:
finding common blocks of functionality and wrapping them in a function.
reducing the human interaction.
Some of the posters on this thread make it sound like this was a conspiracy.
If we had been a brand new company and we came out with a product which kept the exports information in a database instead of a flat file, would you have been this upset? Or would you have enjoyed the experience?
I've been of the flat file bent myself for a long time. Now that I have to maintain the exports file, I'm leaning towards a database for it. There is just too much ambiguity in parsing entries in the host lists - well formed fields, like *shudder* XML, make too much sense.
Anyway, there is no global plan to dumb down the product - just local designs to reduce problems found in customer escalations.
On Wed, 18 Aug 2004, Bruce Arden wrote:
Uh, whoops, now I've got this "/vol/new" export at the end of the file? Hmmm. Harmless, in this case, because at reboot there was no volume named "new" so it wasn't exported... still, this was another little surprise that could have had more serious consequences, and as another long-time Unix/ONTAP hacker I have to lobby against the dumbing down of ONTAP. Any sysadmin qualified to run the box can learn it in an hour or less; filers don't need to be much simpler than they are now. What's next? "Hey, Boeing, this 747 is too hard to fly, make it easier so we can use cheaper pilots."
Cringe.
-- Chris
Chris Lamb wrote:
don't need to be much simpler than they are now. What's next? "Hey, Boeing, this 747 is too hard to fly, make it easier so we can use cheaper pilots."
It did happend : AirbusA320 with a strong enought system able to take in charge navigation computation was able to fly w/ 2 pilots instead of 3.
But I won't disagree w/ you when you say nfs is enought simple today, but we don't have same needs as others could I must admit that NFS codding hadn't changed deeply for a long time and, honestly, perhaps 70% of whole enhencments (of what i figured out) could be really usefull : think about - permanent export with -p switch, - new security level feature at user level w/ kerberos (nfs is finally able to equal CIFS user level security check - at the share/export level, not filesystem), - and what about nfs v4.
auto-export is a stupid idea the filer is not a game box . . . it seems nfs (v2 and v3 at least) was reimplemented in 65 with not enought care and really not enought test remember some bogus parsing of the /etc/exports file wich didn't export as before
netapp, if you listen to us, disable this automatic export at volume creation
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?
Stephane wrote:
...
netapp, if you listen to us, disable this automatic export at volume creation
Completely agree; automatic exports, and especially automatic editing of the exports file is a very bad idea. and, for those of us with RCS or CVS for our filer config files, the editing of /etc/exports is done without checking out the file first. really, REALLY annoying.
also note that "vol create <VOL> -n", which is suppsoed to tell you what vol create *would* do, doesn't tell you that it would edit /etc/exports.
NetApp, please remove this feature, or give me a way to disable it.
-skottie
Chris Thompson wrote:
... Has anyone else been caught out like this? Does anyone else think that these automatic NFS exports shouldn't be happening at all?
Full affirmation!
When using mixed security style, NetApp only supports one single style per filesystem element because of security reasons. E.g. if you were having some Unix-only users, they could never take away the ACL-rights for the CIFS/NTFS side and any Windows guy still could access the 700 unix files. And vice versa... => Not giving the feature of allowing the setting of separate unix- and ntfs-rights at the same files, directories is good for security reasons. I had many customers asking for it, but when they are getting to know about the possible security issue, they agree to the way NetApp chose to implement.
I really would appriciate it, if NetApp could keep this security issue consistant. Only do and only allow what the user/admin explicitely allows you to. The data on the filers are too valuable, for having them exported accidentally!!! I don't want anybody playing around with the isci/fcp/...-Luns over nfs ...
! At least I would like to have an option "nfs.autoexport_new_vols on/off" to handle this. ! (With default turned to: OFF, No automatic exporting)
So probably/hopefully we will see option #250 quite soon. ;-) A little wc -l on the options output:
72 options_534 144 options_622 161 options_63 216 options_641 241 options_65
Just gambling around.... ;-)
Smile & regards! Dirk Schmiedt
-
avarni＠tech.cj.com -
Bruce Arden -
Chris Blackmor -
Chris Lamb -
Chris Thompson -
devnull＠adc.idt.com -
Dirk Schmiedt -
Haynes, Tom -
Jim Harm -
Matt Phelps -
Skottie Miller -
Stephane -
Stéphane Bentebba