]> git.rkrishnan.org Git - tahoe-lafs/tahoe-lafs.git/blob - docs/about.rst
Merge pull request #73 from pataquets/patch-1
[tahoe-lafs/tahoe-lafs.git] / docs / about.rst
1 .. -*- coding: utf-8-with-signature -*-
2
3 Welcome to Tahoe-LAFS!
4 ======================
5
6 Welcome to Tahoe-LAFS_, the first decentralized storage system with
7 *provider-independent security*.
8
9 .. _Tahoe-LAFS: https://tahoe-lafs.org
10
11 What is "provider-independent security"?
12 ========================================
13
14 Every seller of cloud storage services will tell you that their service is
15 "secure".  But what they mean by that is something fundamentally different
16 from what we mean.  What they mean by "secure" is that after you've given
17 them the power to read and modify your data, they try really hard not to let
18 this power be abused.  This turns out to be difficult!  Bugs,
19 misconfigurations, or operator error can accidentally expose your data to
20 another customer or to the public, or can corrupt your data.  Criminals
21 routinely gain illicit access to corporate servers.  Even more insidious is
22 the fact that the employees themselves sometimes violate customer privacy out
23 of carelessness, avarice, or mere curiosity.  The most conscientious of
24 these service providers spend considerable effort and expense trying to
25 mitigate these risks.
26
27 What we mean by "security" is something different.  *The service provider
28 never has the ability to read or modify your data in the first place: never.*
29 If you use Tahoe-LAFS, then all of the threats described above are non-issues
30 to you.  Not only is it easy and inexpensive for the service provider to
31 maintain the security of your data, but in fact they couldn't violate its
32 security if they tried.  This is what we call *provider-independent
33 security*.
34
35 This guarantee is integrated naturally into the Tahoe-LAFS storage system and
36 doesn't require you to perform a manual pre-encryption step or cumbersome key
37 management.  (After all, having to do cumbersome manual operations when
38 storing or accessing your data would nullify one of the primary benefits of
39 using cloud storage in the first place: convenience.)
40
41 Here's how it works:
42
43 .. image:: network-and-reliance-topology.svg
44
45 A "storage grid" is made up of a number of storage servers.  A storage server
46 has direct attached storage (typically one or more hard disks).  A "gateway"
47 uses the storage servers and provides access to the filesystem over HTTP(S)
48 or (S)FTP to tahoe clients.
49 Note that you can find gateway nodes referred sometimes as client nodes. The
50 Tahoe-LAFS architecture defines gateways as "nodes that provide access to
51 files residing in storage nodes". You can see "clients" also referring to
52 processes or programs connecting to a gateway node and performing operations
53 on the grid (for exemple, the CLI binary).
54 Gateways give access to files in the grid via protocols such as HTTP, FTP or
55 SFTP. So, the gateways act as "clients" to other storage nodes at the same
56 time that they are serving files to client programs (WebUI, (S)FTP clients).
57
58 Users do not rely on storage servers to provide *confidentiality* nor
59 *integrity* for their data -- instead all of the data is encrypted and
60 integrity-checked by the gateway, so that the servers can neither read nor
61 modify the contents of the files.
62
63 Users do rely on storage servers for *availability*.  The ciphertext is
64 erasure-coded into ``N`` shares distributed across at least ``H`` distinct
65 storage servers (the default value for ``N`` is 10 and for ``H`` is 7) so
66 that it can be recovered from any ``K`` of these servers (the default
67 value of ``K`` is 3).  Therefore only the failure of ``H-K+1`` (with the
68 defaults, 5) servers can make the data unavailable.
69
70 In the typical deployment mode each user runs her own gateway on her own
71 machine.  This way she relies on her own machine for the confidentiality and
72 integrity of the data.
73
74 An alternate deployment mode is that the gateway runs on a remote machine and
75 the user connects to it over HTTPS or SFTP.  This means that the operator of
76 the gateway can view and modify the user's data (the user *relies on* the
77 gateway for confidentiality and integrity), but the advantage is that the
78 user can access the filesystem with a client that doesn't have the gateway
79 software installed, such as an Internet kiosk or cell phone.
80
81 Access Control
82 ==============
83
84 There are two kinds of files: immutable and mutable. When you upload a file
85 to the storage grid you can choose which kind of file it will be in the
86 grid. Immutable files can't be modified once they have been uploaded.  A
87 mutable file can be modified by someone with read-write access to it. A user
88 can have read-write access to a mutable file or read-only access to it, or no
89 access to it at all.
90
91 A user who has read-write access to a mutable file or directory can give
92 another user read-write access to that file or directory, or they can give
93 read-only access to that file or directory.  A user who has read-only access
94 to a file or directory can give another user read-only access to it.
95
96 When linking a file or directory into a parent directory, you can use a
97 read-write link or a read-only link.  If you use a read-write link, then
98 anyone who has read-write access to the parent directory can gain read-write
99 access to the child, and anyone who has read-only access to the parent
100 directory can gain read-only access to the child.  If you use a read-only
101 link, then anyone who has either read-write or read-only access to the parent
102 directory can gain read-only access to the child.
103
104 For more technical detail, please see the `the doc page`_ on the Wiki.
105
106 .. _the doc page: https://tahoe-lafs.org/trac/tahoe-lafs/wiki/Doc
107
108 Get Started
109 ===========
110
111 To use Tahoe-LAFS, please see quickstart.rst_.
112
113 .. _quickstart.rst: quickstart.rst
114
115 License
116 =======
117
118 Copyright 2006-2012 The Tahoe-LAFS Software Foundation
119
120 You may use this package under the GNU General Public License, version 2 or,
121 at your option, any later version.  See the file COPYING.GPL_ for the terms
122 of the GNU General Public License, version 2.
123
124 You may use this package under the Transitive Grace Period Public Licence,
125 version 1 or, at your option, any later version.  The Transitive Grace Period
126 Public Licence has requirements similar to the GPL except that it allows you
127 to wait for up to twelve months after you redistribute a derived work before
128 releasing the source code of your derived work. See the file
129 COPYING.TGPPL.rst_ for the terms of the Transitive Grace Period Public
130 Licence, version 1.
131
132 (You may choose to use this package under the terms of either licence, at
133 your option.)
134
135 .. _COPYING.GPL: ../COPYING.GPL
136 .. _COPYING.TGPPL.rst: ../COPYING.TGPPL.rst