[Gluster-devel] Security hardening RELRO & PIE flags
Folks, There are some projects which uses compiler/glibc features to strengthen the security claims. Popular distros suggest to harden daemon with RELRO/PIE flags. You could see [1] [2] [3] Partial relro is when you have -Wl,-z,relro in the LDFLAGS for building libraries. Partial relro means that some ELF sections are reordered so that overflows in some likely sections don't affect others and the local offset table is readonly. To get full relro, you also need to have: -Wl,-z,bind_now added to LDFLAGS. What this does is make the Global Offset table and Procedure Lookup Table readonly. This takes some time, so its only worth it for apps that have a real possibility of being attacked. This would be setuid/setgid/setcap and daemons. There are some security critical apps that can have this too. If the apps likely parses files from an untrusted source (internet), then it might also want to have full relro. To enable PIE, you would pass -fPIE -DPIE in the CFLAGS and -pie in the LDFLAGS. What PIE does is randomize the locations of important items such as the base address of an executable and position of libraries, heap, and stack, in a process's address space. Sometimes this is called ASLR. Its designed to make buffer/heap overflow, return into libc attacks much harder. Part of the way it does this is to make a new section in the ELF image that is writable to redirect function calls to the correct address (offsets). This has to be writable because each invocation will have different layouts and needs to be fixed up. So, when you have an application with PIE, you want full relro so that these sections become readonly and not part of an attacker's target areas. I would like to hear from the community whether we should introduce these hardening flags in glusterfs as well. [1] https://fedorahosted.org/fesco/ticket/563 [2] https://wiki.debian.org/Hardening [3] https://wiki.ubuntu.com/Security/Features#relro -- ~Atin ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Security hardening RELRO & PIE flags
IMHO, doing hardening and security should be left the individual distributions and the package maintainers. Generally, each distribution has it's own policies with regards to hardening and security. We as an upstream project cannot decide on what a distribution should do. But we should be ready to fix bugs that could arise when distributions do hardened builds. So, I vote against having these hardening flags added to the base GlusterFS build. But we could add the flags the Fedora spec files which we carry with our source. ~kaushal On Tue, Mar 31, 2015 at 11:49 AM, Atin Mukherjee wrote: > Folks, > > There are some projects which uses compiler/glibc features to strengthen > the security claims. Popular distros suggest to harden daemon with > RELRO/PIE flags. You could see [1] [2] [3] > > Partial relro is when you have -Wl,-z,relro in the LDFLAGS for building > libraries. Partial relro means that some ELF sections are reordered so > that overflows in some likely sections don't affect others and the local > offset table is readonly. To get full relro, you also need to have: > -Wl,-z,bind_now added to LDFLAGS. What this does is make the Global > Offset table and Procedure Lookup Table readonly. This takes > some time, so its only worth it for apps that have a real possibility of > being attacked. This would be setuid/setgid/setcap and daemons. There > are some security critical apps that can have this too. If the apps > likely parses files from an untrusted source (internet), then it might > also want to have full relro. > > To enable PIE, you would pass -fPIE -DPIE in the CFLAGS and -pie in the > LDFLAGS. What PIE does is randomize the locations of important items > such as the base address of an executable and position of libraries, > heap, and stack, in a process's address space. Sometimes this is called > ASLR. Its designed to make buffer/heap overflow, return into libc > attacks much harder. Part of the way it does this is to make a new > section in the ELF image that is writable to redirect function calls to > the correct address (offsets). This has to be writable because each > invocation will have different layouts and needs to be fixed up. So, > when you have an application with PIE, you want full relro so that > these sections become readonly and not part of an attacker's target areas. > > I would like to hear from the community whether we should introduce > these hardening flags in glusterfs as well. > > [1] https://fedorahosted.org/fesco/ticket/563 > [2] https://wiki.debian.org/Hardening > [3] https://wiki.ubuntu.com/Security/Features#relro > -- > ~Atin > ___ > Gluster-devel mailing list > Gluster-devel@gluster.org > http://www.gluster.org/mailman/listinfo/gluster-devel > ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Security hardening RELRO & PIE flags
On Tue, Mar 31, 2015 at 12:20:19PM +0530, Kaushal M wrote: > IMHO, doing hardening and security should be left the individual > distributions and the package maintainers. Generally, each distribution has > it's own policies with regards to hardening and security. We as an upstream > project cannot decide on what a distribution should do. But we should be > ready to fix bugs that could arise when distributions do hardened builds. > > So, I vote against having these hardening flags added to the base GlusterFS > build. But we could add the flags the Fedora spec files which we carry with > our source. Indeed, I agree that the compiler flags should be specified by the distributions. At least Fedora and Debian do this already include (probably different) options within their packaging scripts. We should set the flags we need, but not more. It would be annoying to set default flags that can conflict with others, or which are not (yet) available on architectures that we normally do not test. Niels > > ~kaushal > > On Tue, Mar 31, 2015 at 11:49 AM, Atin Mukherjee > wrote: > > > Folks, > > > > There are some projects which uses compiler/glibc features to strengthen > > the security claims. Popular distros suggest to harden daemon with > > RELRO/PIE flags. You could see [1] [2] [3] > > > > Partial relro is when you have -Wl,-z,relro in the LDFLAGS for building > > libraries. Partial relro means that some ELF sections are reordered so > > that overflows in some likely sections don't affect others and the local > > offset table is readonly. To get full relro, you also need to have: > > -Wl,-z,bind_now added to LDFLAGS. What this does is make the Global > > Offset table and Procedure Lookup Table readonly. This takes > > some time, so its only worth it for apps that have a real possibility of > > being attacked. This would be setuid/setgid/setcap and daemons. There > > are some security critical apps that can have this too. If the apps > > likely parses files from an untrusted source (internet), then it might > > also want to have full relro. > > > > To enable PIE, you would pass -fPIE -DPIE in the CFLAGS and -pie in the > > LDFLAGS. What PIE does is randomize the locations of important items > > such as the base address of an executable and position of libraries, > > heap, and stack, in a process's address space. Sometimes this is called > > ASLR. Its designed to make buffer/heap overflow, return into libc > > attacks much harder. Part of the way it does this is to make a new > > section in the ELF image that is writable to redirect function calls to > > the correct address (offsets). This has to be writable because each > > invocation will have different layouts and needs to be fixed up. So, > > when you have an application with PIE, you want full relro so that > > these sections become readonly and not part of an attacker's target areas. > > > > I would like to hear from the community whether we should introduce > > these hardening flags in glusterfs as well. > > > > [1] https://fedorahosted.org/fesco/ticket/563 > > [2] https://wiki.debian.org/Hardening > > [3] https://wiki.ubuntu.com/Security/Features#relro > > -- > > ~Atin > > ___ > > Gluster-devel mailing list > > Gluster-devel@gluster.org > > http://www.gluster.org/mailman/listinfo/gluster-devel > > > ___ > Gluster-devel mailing list > Gluster-devel@gluster.org > http://www.gluster.org/mailman/listinfo/gluster-devel pgpsJwWPbQkmR.pgp Description: PGP signature ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Security hardening RELRO & PIE flags
I've got responses from couple of folks, would also love hear from others. ~Atin On 03/31/2015 11:49 AM, Atin Mukherjee wrote: > Folks, > > There are some projects which uses compiler/glibc features to strengthen > the security claims. Popular distros suggest to harden daemon with > RELRO/PIE flags. You could see [1] [2] [3] > > Partial relro is when you have -Wl,-z,relro in the LDFLAGS for building > libraries. Partial relro means that some ELF sections are reordered so > that overflows in some likely sections don't affect others and the local > offset table is readonly. To get full relro, you also need to have: > -Wl,-z,bind_now added to LDFLAGS. What this does is make the Global > Offset table and Procedure Lookup Table readonly. This takes > some time, so its only worth it for apps that have a real possibility of > being attacked. This would be setuid/setgid/setcap and daemons. There > are some security critical apps that can have this too. If the apps > likely parses files from an untrusted source (internet), then it might > also want to have full relro. > > To enable PIE, you would pass -fPIE -DPIE in the CFLAGS and -pie in the > LDFLAGS. What PIE does is randomize the locations of important items > such as the base address of an executable and position of libraries, > heap, and stack, in a process's address space. Sometimes this is called > ASLR. Its designed to make buffer/heap overflow, return into libc > attacks much harder. Part of the way it does this is to make a new > section in the ELF image that is writable to redirect function calls to > the correct address (offsets). This has to be writable because each > invocation will have different layouts and needs to be fixed up. So, > when you have an application with PIE, you want full relro so that > these sections become readonly and not part of an attacker's target areas. > > I would like to hear from the community whether we should introduce > these hardening flags in glusterfs as well. > > [1] https://fedorahosted.org/fesco/ticket/563 > [2] https://wiki.debian.org/Hardening > [3] https://wiki.ubuntu.com/Security/Features#relro > -- ~Atin ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Security hardening RELRO & PIE flags
On 03/31/2015 12:45 PM, Niels de Vos wrote: On Tue, Mar 31, 2015 at 12:20:19PM +0530, Kaushal M wrote: IMHO, doing hardening and security should be left the individual distributions and the package maintainers. Generally, each distribution has it's own policies with regards to hardening and security. We as an upstream project cannot decide on what a distribution should do. But we should be ready to fix bugs that could arise when distributions do hardened builds. So, I vote against having these hardening flags added to the base GlusterFS build. But we could add the flags the Fedora spec files which we carry with our source. Indeed, I agree that the compiler flags should be specified by the distributions. At least Fedora and Debian do this already include (probably different) options within their packaging scripts. We should set the flags we need, but not more. It would be annoying to set default flags that can conflict with others, or which are not (yet) available on architectures that we normally do not test. Niels I echo the same. But, just for educational purposes it would be good to know what kind of attack(s) [buffer/heap overflows] GlusterFS is vulnerable as of now and probably fix them if possible (Coverity does the job for us to some extent, correct?). Are there any tools for this out in the open? ~kaushal On Tue, Mar 31, 2015 at 11:49 AM, Atin Mukherjee wrote: Folks, There are some projects which uses compiler/glibc features to strengthen the security claims. Popular distros suggest to harden daemon with RELRO/PIE flags. You could see [1] [2] [3] Partial relro is when you have -Wl,-z,relro in the LDFLAGS for building libraries. Partial relro means that some ELF sections are reordered so that overflows in some likely sections don't affect others and the local offset table is readonly. To get full relro, you also need to have: -Wl,-z,bind_now added to LDFLAGS. What this does is make the Global Offset table and Procedure Lookup Table readonly. This takes some time, so its only worth it for apps that have a real possibility of being attacked. This would be setuid/setgid/setcap and daemons. There are some security critical apps that can have this too. If the apps likely parses files from an untrusted source (internet), then it might also want to have full relro. To enable PIE, you would pass -fPIE -DPIE in the CFLAGS and -pie in the LDFLAGS. What PIE does is randomize the locations of important items such as the base address of an executable and position of libraries, heap, and stack, in a process's address space. Sometimes this is called ASLR. Its designed to make buffer/heap overflow, return into libc attacks much harder. Part of the way it does this is to make a new section in the ELF image that is writable to redirect function calls to the correct address (offsets). This has to be writable because each invocation will have different layouts and needs to be fixed up. So, when you have an application with PIE, you want full relro so that these sections become readonly and not part of an attacker's target areas. I would like to hear from the community whether we should introduce these hardening flags in glusterfs as well. [1] https://fedorahosted.org/fesco/ticket/563 [2] https://wiki.debian.org/Hardening [3] https://wiki.ubuntu.com/Security/Features#relro -- ~Atin ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Security hardening RELRO & PIE flags
On 31 Mar 2015, at 08:15, Niels de Vos wrote: > On Tue, Mar 31, 2015 at 12:20:19PM +0530, Kaushal M wrote: >> IMHO, doing hardening and security should be left the individual >> distributions and the package maintainers. Generally, each distribution has >> it's own policies with regards to hardening and security. We as an upstream >> project cannot decide on what a distribution should do. But we should be >> ready to fix bugs that could arise when distributions do hardened builds. >> >> So, I vote against having these hardening flags added to the base GlusterFS >> build. But we could add the flags the Fedora spec files which we carry with >> our source. > > Indeed, I agree that the compiler flags should be specified by the > distributions. At least Fedora and Debian do this already include > (probably different) options within their packaging scripts. We should > set the flags we need, but not more. It would be annoying to set default > flags that can conflict with others, or which are not (yet) available on > architectures that we normally do not test. First thoughts: :) * We provide our own packaging scripts + distribute rpms/deb's from our own site too. Should we investigate/try these flags out for the packages we build + supply? * Are there changes in our code + debugging practises that would be needed for these security hardening flags to work? If there are, and we don't make these changes ourselves, doesn't that mean we're telling distributions they need to carry their own patch set in order to have a "more secure" GlusterFS? + Justin -- GlusterFS - http://www.gluster.org An open source, distributed file system scaling to several petabytes, and handling thousands of clients. My personal twitter: twitter.com/realjustinclift ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Security hardening RELRO & PIE flags
Hi, Sorry for the top-post. Just to Amplify a but if what Niels has already said—— Yes, in Fedora, the glusterfs.spec file has a line %global _hardened_build 1 at the top. This enables PIE and RELRO in Fedora and EPEL builds. This line exists in the glusterfs.spec.in file in the Gluster source tree too. Debian-based builds have something analogous. (We don't have the Debian packing pieces in our source as we do for RPMs. I wanted it, but the community dictated otherwise.) Using hardened builds gives us the "belt and suspenders" model. IOW we fix things that Coverity finds as fast as we can, and then hardened builds (i.e. PIE + RELRO) close any gaps that Coverity hasn't found or that Coverity has found but haven't been fixed yet. We have a long list of Coverity issues that remain to be worked through. I'm not aware that compiling with PIE and RELRO provide anything of value for mainline development. There are no exra warnings or errors — nothing that the developer would have to change or fix as a function of their ordinary development practices. The executables that a developer produces are meant for development and debugging. PIE and RELRO don't get in the way, but they don't help either. I don't see any reason to enable this in the autoconf config or build. And, BTW, Coverity isn't the end-all solution to code quality and application security. Things like cpp-check, clang-analyze, even just using the Intel, AMD, Clang, and `gcc -pedantic` compilers will find lots of potential bugs just by compiling with them — bugs that gcc doesn't even warn about. Thanks, -- Kaleb On 04/02/2015 07:58 AM, Venky Shankar wrote: On 03/31/2015 12:45 PM, Niels de Vos wrote: On Tue, Mar 31, 2015 at 12:20:19PM +0530, Kaushal M wrote: IMHO, doing hardening and security should be left the individual distributions and the package maintainers. Generally, each distribution has it's own policies with regards to hardening and security. We as an upstream project cannot decide on what a distribution should do. But we should be ready to fix bugs that could arise when distributions do hardened builds. So, I vote against having these hardening flags added to the base GlusterFS build. But we could add the flags the Fedora spec files which we carry with our source. Indeed, I agree that the compiler flags should be specified by the distributions. At least Fedora and Debian do this already include (probably different) options within their packaging scripts. We should set the flags we need, but not more. It would be annoying to set default flags that can conflict with others, or which are not (yet) available on architectures that we normally do not test. Niels I echo the same. But, just for educational purposes it would be good to know what kind of attack(s) [buffer/heap overflows] GlusterFS is vulnerable as of now and probably fix them if possible (Coverity does the job for us to some extent, correct?). Are there any tools for this out in the open? ~kaushal On Tue, Mar 31, 2015 at 11:49 AM, Atin Mukherjee wrote: Folks, There are some projects which uses compiler/glibc features to strengthen the security claims. Popular distros suggest to harden daemon with RELRO/PIE flags. You could see [1] [2] [3] Partial relro is when you have -Wl,-z,relro in the LDFLAGS for building libraries. Partial relro means that some ELF sections are reordered so that overflows in some likely sections don't affect others and the local offset table is readonly. To get full relro, you also need to have: -Wl,-z,bind_now added to LDFLAGS. What this does is make the Global Offset table and Procedure Lookup Table readonly. This takes some time, so its only worth it for apps that have a real possibility of being attacked. This would be setuid/setgid/setcap and daemons. There are some security critical apps that can have this too. If the apps likely parses files from an untrusted source (internet), then it might also want to have full relro. To enable PIE, you would pass -fPIE -DPIE in the CFLAGS and -pie in the LDFLAGS. What PIE does is randomize the locations of important items such as the base address of an executable and position of libraries, heap, and stack, in a process's address space. Sometimes this is called ASLR. Its designed to make buffer/heap overflow, return into libc attacks much harder. Part of the way it does this is to make a new section in the ELF image that is writable to redirect function calls to the correct address (offsets). This has to be writable because each invocation will have different layouts and needs to be fixed up. So, when you have an application with PIE, you want full relro so that these sections become readonly and not part of an attacker's target areas. I would like to hear from the community whether we should introduce these hardening flags in glusterfs as well. [1]https://fedorahosted.org/fesco/ticket/563 [2]https://wiki.debian.org/Hardening [3]https://wiki.ubuntu.com/Securi
Re: [Gluster-devel] Security hardening RELRO & PIE flags
On 04/02/2015 08:22 AM, Kaleb KEITHLEY wrote: Hi, Sorry for the top-post. Just to Amplify a but if what Niels... Just to Amplify a bit of what Niels (Naughty fingers.) -- Kaleb ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Security hardening RELRO & PIE flags
On Thu, Apr 02, 2015 at 01:21:57PM +0100, Justin Clift wrote: > On 31 Mar 2015, at 08:15, Niels de Vos wrote: > > On Tue, Mar 31, 2015 at 12:20:19PM +0530, Kaushal M wrote: > >> IMHO, doing hardening and security should be left the individual > >> distributions and the package maintainers. Generally, each distribution has > >> it's own policies with regards to hardening and security. We as an upstream > >> project cannot decide on what a distribution should do. But we should be > >> ready to fix bugs that could arise when distributions do hardened builds. > >> > >> So, I vote against having these hardening flags added to the base GlusterFS > >> build. But we could add the flags the Fedora spec files which we carry with > >> our source. > > > > Indeed, I agree that the compiler flags should be specified by the > > distributions. At least Fedora and Debian do this already include > > (probably different) options within their packaging scripts. We should > > set the flags we need, but not more. It would be annoying to set default > > flags that can conflict with others, or which are not (yet) available on > > architectures that we normally do not test. > > First thoughts: :) > > * We provide our own packaging scripts + distribute rpms/deb's from our > own site too. > > Should we investigate/try these flags out for the packages we build + > supply? At least for the RPMs, we try to follow the Fedora guidelines and their standard flags. With recent Fedora releases this includes additional hardening flags. > * Are there changes in our code + debugging practises that would be needed > for these security hardening flags to work? > > If there are, and we don't make these changes ourselves, doesn't that > mean we're telling distributions they need to carry their own patch set > in order to have a "more secure" GlusterFS? We have received several patches from the Debian maintainer that improve the handling of these options. When maintainers for distrubutions build GlusterFS and require changes, they either file bugs and/or send patches. I think this works quite well. Niels ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Security hardening RELRO & PIE flags
On 2 Apr 2015, at 14:08, Niels de Vos wrote: > On Thu, Apr 02, 2015 at 01:21:57PM +0100, Justin Clift wrote: >> On 31 Mar 2015, at 08:15, Niels de Vos wrote: >>> On Tue, Mar 31, 2015 at 12:20:19PM +0530, Kaushal M wrote: IMHO, doing hardening and security should be left the individual distributions and the package maintainers. Generally, each distribution has it's own policies with regards to hardening and security. We as an upstream project cannot decide on what a distribution should do. But we should be ready to fix bugs that could arise when distributions do hardened builds. So, I vote against having these hardening flags added to the base GlusterFS build. But we could add the flags the Fedora spec files which we carry with our source. >>> >>> Indeed, I agree that the compiler flags should be specified by the >>> distributions. At least Fedora and Debian do this already include >>> (probably different) options within their packaging scripts. We should >>> set the flags we need, but not more. It would be annoying to set default >>> flags that can conflict with others, or which are not (yet) available on >>> architectures that we normally do not test. >> >> First thoughts: :) >> >> * We provide our own packaging scripts + distribute rpms/deb's from our >>own site too. >> >>Should we investigate/try these flags out for the packages we build + >>supply? > > At least for the RPMs, we try to follow the Fedora guidelines and their > standard flags. With recent Fedora releases this includes additional > hardening flags. > >> * Are there changes in our code + debugging practises that would be needed >>for these security hardening flags to work? >> >>If there are, and we don't make these changes ourselves, doesn't that >>mean we're telling distributions they need to carry their own patch set >>in order to have a "more secure" GlusterFS? > > We have received several patches from the Debian maintainer that improve > the handling of these options. When maintainers for distrubutions build > GlusterFS and require changes, they either file bugs and/or send > patches. I think this works quite well. Thanks Niels. Sounds like we're already in good shape then. :) + Justin -- GlusterFS - http://www.gluster.org An open source, distributed file system scaling to several petabytes, and handling thousands of clients. My personal twitter: twitter.com/realjustinclift ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Security hardening RELRO & PIE flags
On 04/02/2015 06:43 PM, Justin Clift wrote: > On 2 Apr 2015, at 14:08, Niels de Vos wrote: >> On Thu, Apr 02, 2015 at 01:21:57PM +0100, Justin Clift wrote: >>> On 31 Mar 2015, at 08:15, Niels de Vos wrote: On Tue, Mar 31, 2015 at 12:20:19PM +0530, Kaushal M wrote: > IMHO, doing hardening and security should be left the individual > distributions and the package maintainers. Generally, each distribution > has > it's own policies with regards to hardening and security. We as an > upstream > project cannot decide on what a distribution should do. But we should be > ready to fix bugs that could arise when distributions do hardened builds. > > So, I vote against having these hardening flags added to the base > GlusterFS > build. But we could add the flags the Fedora spec files which we carry > with > our source. Indeed, I agree that the compiler flags should be specified by the distributions. At least Fedora and Debian do this already include (probably different) options within their packaging scripts. We should set the flags we need, but not more. It would be annoying to set default flags that can conflict with others, or which are not (yet) available on architectures that we normally do not test. >>> >>> First thoughts: :) >>> >>> * We provide our own packaging scripts + distribute rpms/deb's from our >>>own site too. >>> >>>Should we investigate/try these flags out for the packages we build + >>>supply? >> >> At least for the RPMs, we try to follow the Fedora guidelines and their >> standard flags. With recent Fedora releases this includes additional >> hardening flags. >> >>> * Are there changes in our code + debugging practises that would be needed >>>for these security hardening flags to work? >>> >>>If there are, and we don't make these changes ourselves, doesn't that >>>mean we're telling distributions they need to carry their own patch set >>>in order to have a "more secure" GlusterFS? >> >> We have received several patches from the Debian maintainer that improve >> the handling of these options. When maintainers for distrubutions build >> GlusterFS and require changes, they either file bugs and/or send >> patches. I think this works quite well. > > Thanks Niels. Sounds like we're already in good shape then. :) Allright. With this I consider there is no need of upstream changes for this. Thank you all for your insights and feedback. ~Atin > > + Justin > > -- > GlusterFS - http://www.gluster.org > > An open source, distributed file system scaling to several > petabytes, and handling thousands of clients. > > My personal twitter: twitter.com/realjustinclift > > ___ > Gluster-devel mailing list > Gluster-devel@gluster.org > http://www.gluster.org/mailman/listinfo/gluster-devel > -- ~Atin ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
