7 ms·

Of course, the first commenter "willy" repeats the canard that statelessness makes no sense: > The very notion of a stateless filesystem is ridiculous. Filesys

by smarks 4y ago

Of course, the first commenter "willy" repeats the canard that statelessness makes no sense: > The very notion of a stateless filesystem is ridiculous. Filesystems exist to store state. It's the protocol that's stateless, not the filesystem. I thought the article made a reasonable attempt to explain that. Overall the article is reasonable but it omits one of the big issues with NFSv2, which is synchronous writes. Those Sun NFS implementations were based on Sun's RPC system; the server was required not to reply until the write had been committed to stable storage. There was a mount option to disable this, but if you enabled it, it exposed you to data corruption. Certain vendors (SGI, if I recall correctly) at some point claimed their NFS was faster than Sun's, but it implemented asynchronous writes. This resulted in the expected arguments over protocol compliance and reliability vs. performance. This phenomenon led to various hardware "NFS accelerator" solutions that put an NVRAM write cache in front of the disk in order to speed up synchronous writes. I believe Legato and the still-existing NetApp were based on such technology. Eventually the synchronous writes issue was resolved, possibly by NFSv3, though the details escape me.

wahern 4y ago
NFS is basically the original S3. Both are useful for similar scenarios (maybe a slightly narrow subset for NFS (especially in later incarnations), and the semantics of both break down in similar ways. I've always just presumed the development of EFS recapitulated the evolution of NFS, in many cases quite literally, considering the EFS protocol is a flavor of NFS. S3 buckets are just blobs with GUIDs in a flat namespace, which is literally what stateless NFS is--every "file" has a persistent UID (GUID if you assume host identifiers are unique), providing a simple handle for submitting idempotent block-oriented read and write operations. Theoretically, EFS could just be a fairly simple interface over S3, especially if you can implicitly wave away many of the caveats (e.g. wrt shared writes) by simply pointing out they have existed and mostly been tolerated in NFS environments for decades.
- geertj 4y ago
  (PM-T on the EFS team) S3 and EFS actually are quite different. Files on EFS are update-able, rename-able and link-able (I.e what’s expected from a file system), while S3 objects are immutable once they are created. This comes from the underlying data structures. EFS uses inodes and directories while S3 is more of a flat map. Protocol-wise EFS uses standard NFS 4.1. We added some optional innovations outside the protocol that you can use through our mount helper (mount.efs). This includes in-transit encryption with TLS (you can basically talk TLS to our endpoint and we will detect that automatically), and we support strong client auth using SigV4 over x509 client certificate.
  - throw0101a 4y ago
    > This includes in-transit encryption with TLS […] Will EFS be updated to use the NFS-TLS RFC once it settles down some? * https://datatracker.ietf.org/doc/html/draft-ietf-nfsv4-rpc-tls https://datatracker.ietf.org/doc/html/draft-ietf-nfsv4-rpc-t...
    - chasil 4y ago
      It looked like work on this had stopped. Is there still hope that it might become a published RFC?
      - throw0101a 4y ago
        Activity on the NFSv4 mailing list: * https://mailarchive.ietf.org/arch/browse/nfsv4/ https://mailarchive.ietf.org/arch/browse/nfsv4/ But no recent commits to the draft: * https://github.com/chucklever/i-d-rpc-tls https://github.com/chucklever/i-d-rpc-tls
        chasil 4y ago
        Thanks for the mailing list link. Here is the status: "This one had to be paused for a bit to work out some issues around using a wider type to hold the epoch value, to accomodate some DTLS-SCTP use cases involving associations expected to remain up for years at a time. https://github.com/tlswg/dtls13-spec/issues/249 https://github.com/tlswg/dtls13-spec/issues/249 ends up covering most of the topics, though the discussion is a bit jumbled. We have a proposed solution with almost all the signoffs needed, and should be attempting to confirm this approach at the session at IETF 112 next week... "I'm sorry that these have been taking so long; these delays were unexpected."
      - geertj 4y ago
        > It looked like work on this had stopped. Is there still hope that it might become a published RFC? I don't know, I hope it will. Not to go on too much of a tangent, and at the risk of sounding like my employer's fanboy, but one of the great things about working at AWS (I'm being honest, and yes we are hiring SDEs and PMs) is that we 100% focus on the customer. When our customers told us they needed encryption in transit, we figured out we could simply offer them transport-level TLS independent from the application-level RPC protocol. It may not have been the standards-compliant approach, but our customers have been enjoying fast reliable encryption for over 4 years now [1]. It solves a real problem because customers have compliance requirements. [1] https://aws.amazon.com/about-aws/whats-new/2018/04/amazon-efs-now-supports-encryption-of-data-in-transit/ https://aws.amazon.com/about-aws/whats-new/2018/04/amazon-ef...
chasil 4y ago
There is a historical document by Olaf Kirch that addresses many aspects of the stateless design. It also has some discussion of the indempotent replay cache that is also in the original article. https://www.kernel.org/doc/ols/2006/ols2006v2-pages-59-72.pdf https://www.kernel.org/doc/ols/2006/ols2006v2-pages-59-72.pd...
- smarks 4y ago
  “Why NFS Sucks” (2006), picking on a protocol that was over 20 years old at that point. Also cites “The Unix-Haters Handbook” in the abstract. Two strikes against its credibility already. However, I did skim the paper, and it seems halfway reasonable, so I suppose I should read the whole thing. Of course nothing is above criticism, and there are many valid criticisms of NFS; but leading with “sucks” is just lazy.
  - chasil 4y ago
    If you think that was bad, just listen to what Theo de Raadt had to say. "NFSv4 is a gigantic joke on everyone....NFSv4 is not on our roadmap. It is a ridiculous bloated protocol which they keep adding crap to. In about a decade the people who actually start auditing it are going to see all the mistakes that it hides. "The design process followed by the NFSv4 team members matches the methodology taken by the IPV6 people. (As in, once a mistake is made, and 4 people are running the test code, it is a fact on the ground and cannot be changed again.) The result is an unrefined piece of trash." https://blog.fosketts.net/2015/02/03/vsphere-6-nfs-41-finally/ https://blog.fosketts.net/2015/02/03/vsphere-6-nfs-41-finall...
    - smarks 4y ago
      OK, I read the Olaf Kirch article, and the "NFS Sucks" title is mostly clickbait. There are indeed a bunch of shortcomings in NFS that he points out, that are partially addressed by NFSv4. He also admits that (as of 2006) there isn't anything better. Locking has historically always been a problem in NFS. Kirch mentions that NLM was designed for Posix semantics only. I frankly don't know if NLM is related to `rpc.lockd` which appeared in SunOS 4 and possibly even SunOS 3 (mid 1980s at this point) which well predates anything having to do with Posix. Part of the problem is the confused state of file locking in the Unix world, even for local files. There was BSD-style `flock` and SYSV-style `lockf` and there might even have been multiple versions of those. Implementing these in a distributed system would have been terribly complex. Even at Sun, at least through the mid 1990s, the conventional wisdom was to avoid file locking. If you really needed something that supported distributed updates, it was better to use a purpose-built network protocol. One thing "willy" got right in his comment is that NFS is an example of "worse is better". In its early version, it had the benefit of being relatively simple, as acknowledged in the LWN article. This made it easy to port and reimplement and thus it became widespread. Of course being simple means there are lots of tradeoffs and shortcomings. To address these you need to make things more complex, and now things are "ridiculous" and "bloated". Oh well.
DonHopkins 4y ago
NFS originally stood for "No File Security". The NFS protocol wasn't just stateless, but also securityless! Stewart, remember the open secret that almost everybody at Sun knew about, in which you could tftp a host's /etc/exports (because tftp was set up by default in a way that left it wide open to anyone from anywhere reading files in /etc) to learn the name of all the servers a host allowed to mount its file system, and then in a root shell simply go "hostname foo ; mount remote:/dir /mnt ; hostname `hostname`" to temporarily change the CLIENT's hostname to the name of a host that the SERVER allowed to mount the directory, then mount it (claiming to be an allowed client), then switch it back? That's right, the server didn't bother checking the client's IP address against the host name it claimed to be in the NFS mountd request. That's right: the protocol itself let the client tell the server what its host name was, and the server implementation didn't check that against the client's ip address. Nice professional protocol design and implementation, huh? Yes, that actually worked, because the NFS protocol laughably trusted the CLIENT to identify its host name for security purposes. That level of "trust" was built into the original NFS protocol and implementation from day one, by the geniuses at Sun who originally designed it. The network is the computer is insecure, indeed. And most engineers at Sun knew that (and many often took advantage of it). NFS security was a running joke, thus the moniker "No File Security". But Sun proudly shipped it to customers anyway, configured with terribly insecure defaults that let anybody on the internet mount your file system. (That "feature" was undocumented, of course.) While I was a summer intern at Sun in 1987, somebody at Sun laughingly told me about it, explaining that was how everybody at Sun read each other's email. So I tried it out by using that technique to mount remote NFS directories from Rutgers, CMU, and UMD onto my workstation at Sun. It was slow but it worked just fine. I told my friend Ron Natalie at Rutgers, who was Associate Director of CCIS at the time, that I was able to access his private file systems over the internet from Sun, and he rightfully freaked out, because as a huge Sun customer in charge of security, nobody at Sun had ever told him about how incredibly insecure NFS actually was before, despite all Sun's promises. (Technically I was probably violating the terms of my NDA with Sun by telling him that, but tough cookies.) For all Sun's lip service about NFS and networks and computers and security, it was widely know internally at Sun that NFS had No File Security, which was why it was such a running inside joke that Sun knowingly shipped it to their customers with such flagrantly terrible defaults, but didn't care to tell anyone who followed their advice and used their software that they were leaving their file systems wide open. Here is an old news-makers email from Ron from Interop88 that mentions mounting NFS directories over the internet -- by then after I'd told him about NFS's complete lack of security, so he'd probably slightly secured his own servers by overriding the tftp defaults by then, and was able to mount it because he remembered one of the host names in /etc/exports and didn't need to fetch it with tftp to discover it: >From: Ron Natalie <elbereth.rutgers.edu!ron.rutgers.edu!ron@rutgers.edu> Date: Wed, Oct 5, 1988, 4:09 AM To: NeWS-makers@brillig.umd.edu >I love a trade show that I can walk into almost any booth and get logged in at reasonable speed to my home machine. One neat experiment was that The Wollongong Group provided a Sun 3/60C for a public mail reading terminal. It was lacking a windowing system, so I decided to see if I could start up NeWS on it. In order to do that, I NFS mounted the /usr partition from a Rutgers machine and Symlinked /usr/NeWS to the appropriate directory. This worked amazingly well. >(The guys from the Apple booth thought that NeWS was pretty neat, I showed them how to change the menus by just editing the user.ps file.) >-Ron I posted about this fact earlier: https://news.ycombinator.com/item?id=21102724 https://news.ycombinator.com/item?id=21102724 >DonHopkins on Sept 28, 2019 | parent | context | favorite | on: A developer goes to a DevOps conference >I love the incredibly vague job title "Member, Technical Staff" I had at Sun. It could cover anything from kernel hacking to HVAC repair! >At least I had root access to my own workstation (and everybody else's in the company, thanks to the fact that NFS actually stood for No File Security). >[In the late 80's and early 90's, NFSv2 clients could change their hostname to anything they wanted before doing a mount ("hostname foobar; mount server:/foobar /mnt ; hostname original"), and that name would be sent in the mount request, and the server trusted the name the client claimed to be without checking it against the ip address, then looked it up in /etc/exports, and happily returned a file handle. >If the NFS server or any of its clients were on your local network, you could snoop file handles by putting your ethernet card into promiscuous mode. >And of course NFS servers often ran TFTP servers by default (for booting diskless clients), so you could usually read an NFS server's /etc/exports file to find out what client hostnames it allowed, then change your hostname to one of those before mounting any remote file system you wanted from the NFS server. >And yes, TFTP and NFS and this security hole you could drive the space shuttle through worked just fine over the internet, not just the local area network.] Sun's track record on network security isn't exactly "stellar" and has "burned" a lot of people (pardon the terrible puns, which can't hold a candle to IBM's "Eclipse" pun). The other gaping security hole at Sun I reported was just after the Robert T Morris Worm incident, as I explained to Martha Zimet: >Oh yeah, there was that one time I accidentally hacked sun.com’s sendmail server, the day after the Morris worm. >The worm was getting in via sendmail’s DEBUG command, which was usually enabled by default. >One of the first helpful responses that somebody emailed around was a suggestion for blocking the worm by editing your sendmail binary, searching for DEBUG, and replacing the D with a NULL character. >Which the genius running sun.com apparently did. >That had the effect of disabling the DEBUG command, but enabling the zero-length string command! >So as I often did, I went “telnet sun.com 25” to EXPN some news-makers email addresses that had been bouncing, and first hit return a couple of times to flush the telnet negotiation characters it sends, so the second return put it in debug mode, and the EXPN returned a whole page full of diagnostic information I wasn’t expecting! >I reported the problem to postmaster@sun.com and they were like “sorry oops”. I've mention that one a couple times before: https://news.ycombinator.com/item?id=29250313 https://news.ycombinator.com/item?id=29250313 https://news.ycombinator.com/item?id=21101321 https://news.ycombinator.com/item?id=21101321
mprovost 4y ago
Yes, Legato's first product was the Prestoserve NFS accelerator card (in 1989!).[0] NetApp's implementation mirrored the cache across two servers in a cluster with an interconnect. NFSv3 "fixed" the write issue by adding a separate COMMIT RPC: "The write throughput bottleneck caused by the synchronous definition of write in the NFS version 2 protocol has been addressed by adding support so that the NFS server can do unsafe writes. Unsafe writes are writes which have not been committed to stable storage before the operation returns. This specification defines a method for committing these unsafe writes to stable storage in a reliable way."[1] [0] https://twitter.com/aka_pugs/status/1225665691472166912 https://twitter.com/aka_pugs/status/1225665691472166912 [1] https://datatracker.ietf.org/doc/html/rfc1813#section-1.1 https://datatracker.ietf.org/doc/html/rfc1813#section-1.1
koverstreet 4y ago
That's Matthew Wilcox you're referring to, and he's right. It's not just about reads and writes - doing a stateless protocol for a block device is fine. Think more about unlink...

by smarks 4y ago

wahern 4y ago

NFS is basically the original S3. Both are useful for similar scenarios (maybe a slightly narrow subset for NFS (especially in later incarnations), and the semantics of both break down in similar ways. I've always just presumed the development of EFS recapitulated the evolution of NFS, in many cases quite literally, considering the EFS protocol is a flavor of NFS. S3 buckets are just blobs with GUIDs in a flat namespace, which is literally what stateless NFS is--every "file" has a persistent UID (GUID if you assume host identifiers are unique), providing a simple handle for submitting idempotent block-oriented read and write operations. Theoretically, EFS could just be a fairly simple interface over S3, especially if you can implicitly wave away many of the caveats (e.g. wrt shared writes) by simply pointing out they have existed and mostly been tolerated in NFS environments for decades.

geertj 4y ago
(PM-T on the EFS team) S3 and EFS actually are quite different. Files on EFS are update-able, rename-able and link-able (I.e what’s expected from a file system), while S3 objects are immutable once they are created. This comes from the underlying data structures. EFS uses inodes and directories while S3 is more of a flat map. Protocol-wise EFS uses standard NFS 4.1. We added some optional innovations outside the protocol that you can use through our mount helper (mount.efs). This includes in-transit encryption with TLS (you can basically talk TLS to our endpoint and we will detect that automatically), and we support strong client auth using SigV4 over x509 client certificate.
- throw0101a 4y ago
  > This includes in-transit encryption with TLS […] Will EFS be updated to use the NFS-TLS RFC once it settles down some? * https://datatracker.ietf.org/doc/html/draft-ietf-nfsv4-rpc-tls https://datatracker.ietf.org/doc/html/draft-ietf-nfsv4-rpc-t...
  - chasil 4y ago
    It looked like work on this had stopped. Is there still hope that it might become a published RFC?
    - throw0101a 4y ago
      Activity on the NFSv4 mailing list: * https://mailarchive.ietf.org/arch/browse/nfsv4/ https://mailarchive.ietf.org/arch/browse/nfsv4/ But no recent commits to the draft: * https://github.com/chucklever/i-d-rpc-tls https://github.com/chucklever/i-d-rpc-tls
      - chasil 4y ago
        Thanks for the mailing list link. Here is the status: "This one had to be paused for a bit to work out some issues around using a wider type to hold the epoch value, to accomodate some DTLS-SCTP use cases involving associations expected to remain up for years at a time. https://github.com/tlswg/dtls13-spec/issues/249 https://github.com/tlswg/dtls13-spec/issues/249 ends up covering most of the topics, though the discussion is a bit jumbled. We have a proposed solution with almost all the signoffs needed, and should be attempting to confirm this approach at the session at IETF 112 next week... "I'm sorry that these have been taking so long; these delays were unexpected."
    - geertj 4y ago
      > It looked like work on this had stopped. Is there still hope that it might become a published RFC? I don't know, I hope it will. Not to go on too much of a tangent, and at the risk of sounding like my employer's fanboy, but one of the great things about working at AWS (I'm being honest, and yes we are hiring SDEs and PMs) is that we 100% focus on the customer. When our customers told us they needed encryption in transit, we figured out we could simply offer them transport-level TLS independent from the application-level RPC protocol. It may not have been the standards-compliant approach, but our customers have been enjoying fast reliable encryption for over 4 years now [1]. It solves a real problem because customers have compliance requirements. [1] https://aws.amazon.com/about-aws/whats-new/2018/04/amazon-efs-now-supports-encryption-of-data-in-transit/ https://aws.amazon.com/about-aws/whats-new/2018/04/amazon-ef...

chasil 4y ago

There is a historical document by Olaf Kirch that addresses many aspects of the stateless design. It also has some discussion of the indempotent replay cache that is also in the original article. https://www.kernel.org/doc/ols/2006/ols2006v2-pages-59-72.pdf https://www.kernel.org/doc/ols/2006/ols2006v2-pages-59-72.pd...

smarks 4y ago
“Why NFS Sucks” (2006), picking on a protocol that was over 20 years old at that point. Also cites “The Unix-Haters Handbook” in the abstract. Two strikes against its credibility already. However, I did skim the paper, and it seems halfway reasonable, so I suppose I should read the whole thing. Of course nothing is above criticism, and there are many valid criticisms of NFS; but leading with “sucks” is just lazy.
- chasil 4y ago
  If you think that was bad, just listen to what Theo de Raadt had to say. "NFSv4 is a gigantic joke on everyone....NFSv4 is not on our roadmap. It is a ridiculous bloated protocol which they keep adding crap to. In about a decade the people who actually start auditing it are going to see all the mistakes that it hides. "The design process followed by the NFSv4 team members matches the methodology taken by the IPV6 people. (As in, once a mistake is made, and 4 people are running the test code, it is a fact on the ground and cannot be changed again.) The result is an unrefined piece of trash." https://blog.fosketts.net/2015/02/03/vsphere-6-nfs-41-finally/ https://blog.fosketts.net/2015/02/03/vsphere-6-nfs-41-finall...
  - smarks 4y ago
    OK, I read the Olaf Kirch article, and the "NFS Sucks" title is mostly clickbait. There are indeed a bunch of shortcomings in NFS that he points out, that are partially addressed by NFSv4. He also admits that (as of 2006) there isn't anything better. Locking has historically always been a problem in NFS. Kirch mentions that NLM was designed for Posix semantics only. I frankly don't know if NLM is related to `rpc.lockd` which appeared in SunOS 4 and possibly even SunOS 3 (mid 1980s at this point) which well predates anything having to do with Posix. Part of the problem is the confused state of file locking in the Unix world, even for local files. There was BSD-style `flock` and SYSV-style `lockf` and there might even have been multiple versions of those. Implementing these in a distributed system would have been terribly complex. Even at Sun, at least through the mid 1990s, the conventional wisdom was to avoid file locking. If you really needed something that supported distributed updates, it was better to use a purpose-built network protocol. One thing "willy" got right in his comment is that NFS is an example of "worse is better". In its early version, it had the benefit of being relatively simple, as acknowledged in the LWN article. This made it easy to port and reimplement and thus it became widespread. Of course being simple means there are lots of tradeoffs and shortcomings. To address these you need to make things more complex, and now things are "ridiculous" and "bloated". Oh well.

DonHopkins 4y ago

NFS originally stood for "No File Security". The NFS protocol wasn't just stateless, but also securityless! Stewart, remember the open secret that almost everybody at Sun knew about, in which you could tftp a host's /etc/exports (because tftp was set up by default in a way that left it wide open to anyone from anywhere reading files in /etc) to learn the name of all the servers a host allowed to mount its file system, and then in a root shell simply go "hostname foo ; mount remote:/dir /mnt ; hostname `hostname`" to temporarily change the CLIENT's hostname to the name of a host that the SERVER allowed to mount the directory, then mount it (claiming to be an allowed client), then switch it back? That's right, the server didn't bother checking the client's IP address against the host name it claimed to be in the NFS mountd request. That's right: the protocol itself let the client tell the server what its host name was, and the server implementation didn't check that against the client's ip address. Nice professional protocol design and implementation, huh? Yes, that actually worked, because the NFS protocol laughably trusted the CLIENT to identify its host name for security purposes. That level of "trust" was built into the original NFS protocol and implementation from day one, by the geniuses at Sun who originally designed it. The network is the computer is insecure, indeed. And most engineers at Sun knew that (and many often took advantage of it). NFS security was a running joke, thus the moniker "No File Security". But Sun proudly shipped it to customers anyway, configured with terribly insecure defaults that let anybody on the internet mount your file system. (That "feature" was undocumented, of course.) While I was a summer intern at Sun in 1987, somebody at Sun laughingly told me about it, explaining that was how everybody at Sun read each other's email. So I tried it out by using that technique to mount remote NFS directories from Rutgers, CMU, and UMD onto my workstation at Sun. It was slow but it worked just fine. I told my friend Ron Natalie at Rutgers, who was Associate Director of CCIS at the time, that I was able to access his private file systems over the internet from Sun, and he rightfully freaked out, because as a huge Sun customer in charge of security, nobody at Sun had ever told him about how incredibly insecure NFS actually was before, despite all Sun's promises. (Technically I was probably violating the terms of my NDA with Sun by telling him that, but tough cookies.) For all Sun's lip service about NFS and networks and computers and security, it was widely know internally at Sun that NFS had No File Security, which was why it was such a running inside joke that Sun knowingly shipped it to their customers with such flagrantly terrible defaults, but didn't care to tell anyone who followed their advice and used their software that they were leaving their file systems wide open. Here is an old news-makers email from Ron from Interop88 that mentions mounting NFS directories over the internet -- by then after I'd told him about NFS's complete lack of security, so he'd probably slightly secured his own servers by overriding the tftp defaults by then, and was able to mount it because he remembered one of the host names in /etc/exports and didn't need to fetch it with tftp to discover it: >From: Ron Natalie <elbereth.rutgers.edu!ron.rutgers.edu!ron@rutgers.edu> Date: Wed, Oct 5, 1988, 4:09 AM To: NeWS-makers@brillig.umd.edu >I love a trade show that I can walk into almost any booth and get logged in at reasonable speed to my home machine. One neat experiment was that The Wollongong Group provided a Sun 3/60C for a public mail reading terminal. It was lacking a windowing system, so I decided to see if I could start up NeWS on it. In order to do that, I NFS mounted the /usr partition from a Rutgers machine and Symlinked /usr/NeWS to the appropriate directory. This worked amazingly well. >(The guys from the Apple booth thought that NeWS was pretty neat, I showed them how to change the menus by just editing the user.ps file.) >-Ron I posted about this fact earlier: https://news.ycombinator.com/item?id=21102724 https://news.ycombinator.com/item?id=21102724 >DonHopkins on Sept 28, 2019 | parent | context | favorite | on: A developer goes to a DevOps conference >I love the incredibly vague job title "Member, Technical Staff" I had at Sun. It could cover anything from kernel hacking to HVAC repair! >At least I had root access to my own workstation (and everybody else's in the company, thanks to the fact that NFS actually stood for No File Security). >[In the late 80's and early 90's, NFSv2 clients could change their hostname to anything they wanted before doing a mount ("hostname foobar; mount server:/foobar /mnt ; hostname original"), and that name would be sent in the mount request, and the server trusted the name the client claimed to be without checking it against the ip address, then looked it up in /etc/exports, and happily returned a file handle. >If the NFS server or any of its clients were on your local network, you could snoop file handles by putting your ethernet card into promiscuous mode. >And of course NFS servers often ran TFTP servers by default (for booting diskless clients), so you could usually read an NFS server's /etc/exports file to find out what client hostnames it allowed, then change your hostname to one of those before mounting any remote file system you wanted from the NFS server. >And yes, TFTP and NFS and this security hole you could drive the space shuttle through worked just fine over the internet, not just the local area network.] Sun's track record on network security isn't exactly "stellar" and has "burned" a lot of people (pardon the terrible puns, which can't hold a candle to IBM's "Eclipse" pun). The other gaping security hole at Sun I reported was just after the Robert T Morris Worm incident, as I explained to Martha Zimet: >Oh yeah, there was that one time I accidentally hacked sun.com’s sendmail server, the day after the Morris worm. >The worm was getting in via sendmail’s DEBUG command, which was usually enabled by default. >One of the first helpful responses that somebody emailed around was a suggestion for blocking the worm by editing your sendmail binary, searching for DEBUG, and replacing the D with a NULL character. >Which the genius running sun.com apparently did. >That had the effect of disabling the DEBUG command, but enabling the zero-length string command! >So as I often did, I went “telnet sun.com 25” to EXPN some news-makers email addresses that had been bouncing, and first hit return a couple of times to flush the telnet negotiation characters it sends, so the second return put it in debug mode, and the EXPN returned a whole page full of diagnostic information I wasn’t expecting! >I reported the problem to postmaster@sun.com and they were like “sorry oops”. I've mention that one a couple times before: https://news.ycombinator.com/item?id=29250313 https://news.ycombinator.com/item?id=29250313 https://news.ycombinator.com/item?id=21101321 https://news.ycombinator.com/item?id=21101321

mprovost 4y ago

Yes, Legato's first product was the Prestoserve NFS accelerator card (in 1989!).[0] NetApp's implementation mirrored the cache across two servers in a cluster with an interconnect. NFSv3 "fixed" the write issue by adding a separate COMMIT RPC: "The write throughput bottleneck caused by the synchronous definition of write in the NFS version 2 protocol has been addressed by adding support so that the NFS server can do unsafe writes. Unsafe writes are writes which have not been committed to stable storage before the operation returns. This specification defines a method for committing these unsafe writes to stable storage in a reliable way."[1] [0] https://twitter.com/aka_pugs/status/1225665691472166912 https://twitter.com/aka_pugs/status/1225665691472166912 [1] https://datatracker.ietf.org/doc/html/rfc1813#section-1.1 https://datatracker.ietf.org/doc/html/rfc1813#section-1.1

koverstreet 4y ago

That's Matthew Wilcox you're referring to, and he's right. It's not just about reads and writes - doing a stateless protocol for a block device is fine. Think more about unlink...