1 | .. -*- coding: utf-8-with-signature -*- |
---|
2 | |
---|
3 | ********************** |
---|
4 | Welcome to Tahoe-LAFS! |
---|
5 | ********************** |
---|
6 | |
---|
7 | What is Tahoe-LAFS? |
---|
8 | =================== |
---|
9 | |
---|
10 | Welcome to Tahoe-LAFS_, the first decentralized storage system with |
---|
11 | *provider-independent security*. |
---|
12 | |
---|
13 | Tahoe-LAFS is a system that helps you to store files. You run a client |
---|
14 | program on your computer, which talks to one or more storage servers on other |
---|
15 | computers. When you tell your client to store a file, it will encrypt that |
---|
16 | file, encode it into multiple pieces, then spread those pieces out among |
---|
17 | multiple servers. The pieces are all encrypted and protected against |
---|
18 | modifications. Later, when you ask your client to retrieve the file, it will |
---|
19 | find the necessary pieces, make sure they haven't been corrupted, reassemble |
---|
20 | them, and decrypt the result. |
---|
21 | |
---|
22 | The client creates more pieces (or "shares") than it will eventually need, so |
---|
23 | even if some of the servers fail, you can still get your data back. Corrupt |
---|
24 | shares are detected and ignored, so the system can tolerate server-side |
---|
25 | hard-drive errors. All files are encrypted (with a unique key) before |
---|
26 | uploading, so even a malicious server operator cannot read your data. The |
---|
27 | only thing you ask of the servers is that they can (usually) provide the |
---|
28 | shares when you ask for them: you aren't relying upon them for |
---|
29 | confidentiality, integrity, or absolute availability. |
---|
30 | |
---|
31 | .. _Tahoe-LAFS: https://tahoe-lafs.org |
---|
32 | |
---|
33 | What is "provider-independent security"? |
---|
34 | ======================================== |
---|
35 | |
---|
36 | Every seller of cloud storage services will tell you that their service is |
---|
37 | "secure". But what they mean by that is something fundamentally different |
---|
38 | from what we mean. What they mean by "secure" is that after you've given |
---|
39 | them the power to read and modify your data, they try really hard not to let |
---|
40 | this power be abused. This turns out to be difficult! Bugs, |
---|
41 | misconfigurations, or operator error can accidentally expose your data to |
---|
42 | another customer or to the public, or can corrupt your data. Criminals |
---|
43 | routinely gain illicit access to corporate servers. Even more insidious is |
---|
44 | the fact that the employees themselves sometimes violate customer privacy out |
---|
45 | of carelessness, avarice, or mere curiosity. The most conscientious of |
---|
46 | these service providers spend considerable effort and expense trying to |
---|
47 | mitigate these risks. |
---|
48 | |
---|
49 | What we mean by "security" is something different. *The service provider |
---|
50 | never has the ability to read or modify your data in the first place: never.* |
---|
51 | If you use Tahoe-LAFS, then all of the threats described above are non-issues |
---|
52 | to you. Not only is it easy and inexpensive for the service provider to |
---|
53 | maintain the security of your data, but in fact they couldn't violate its |
---|
54 | security if they tried. This is what we call *provider-independent |
---|
55 | security*. |
---|
56 | |
---|
57 | This guarantee is integrated naturally into the Tahoe-LAFS storage system and |
---|
58 | doesn't require you to perform a manual pre-encryption step or cumbersome key |
---|
59 | management. (After all, having to do cumbersome manual operations when |
---|
60 | storing or accessing your data would nullify one of the primary benefits of |
---|
61 | using cloud storage in the first place: convenience.) |
---|
62 | |
---|
63 | Here's how it works: |
---|
64 | |
---|
65 | .. image:: network-and-reliance-topology.svg |
---|
66 | |
---|
67 | A "storage grid" is made up of a number of storage servers. A storage server |
---|
68 | has direct attached storage (typically one or more hard disks). A "gateway" |
---|
69 | communicates with storage nodes, and uses them to provide access to the |
---|
70 | grid over protocols such as HTTP(S) and SFTP. |
---|
71 | |
---|
72 | Note that you can find "client" used to refer to gateway nodes (which act as |
---|
73 | a client to storage servers), and also to processes or programs connecting to |
---|
74 | a gateway node and performing operations on the grid -- for example, a CLI |
---|
75 | command, Web browser, or SFTP client. |
---|
76 | |
---|
77 | Users do not rely on storage servers to provide *confidentiality* nor |
---|
78 | *integrity* for their data -- instead all of the data is encrypted and |
---|
79 | integrity-checked by the gateway, so that the servers can neither read nor |
---|
80 | modify the contents of the files. |
---|
81 | |
---|
82 | Users do rely on storage servers for *availability*. The ciphertext is |
---|
83 | erasure-coded into ``N`` shares distributed across at least ``H`` distinct |
---|
84 | storage servers (the default value for ``N`` is 10 and for ``H`` is 7) so |
---|
85 | that it can be recovered from any ``K`` of these servers (the default |
---|
86 | value of ``K`` is 3). Therefore only the failure of ``H-K+1`` (with the |
---|
87 | defaults, 5) servers can make the data unavailable. |
---|
88 | |
---|
89 | In the typical deployment mode each user runs her own gateway on her own |
---|
90 | machine. This way she relies on her own machine for the confidentiality and |
---|
91 | integrity of the data. |
---|
92 | |
---|
93 | An alternate deployment mode is that the gateway runs on a remote machine and |
---|
94 | the user connects to it over HTTPS or SFTP. This means that the operator of |
---|
95 | the gateway can view and modify the user's data (the user *relies on* the |
---|
96 | gateway for confidentiality and integrity), but the advantage is that the |
---|
97 | user can access the Tahoe-LAFS grid with a client that doesn't have the |
---|
98 | gateway software installed, such as an Internet kiosk or cell phone. |
---|
99 | |
---|
100 | Access Control |
---|
101 | ============== |
---|
102 | |
---|
103 | There are two kinds of files: immutable and mutable. When you upload a file |
---|
104 | to the storage grid you can choose which kind of file it will be in the |
---|
105 | grid. Immutable files can't be modified once they have been uploaded. A |
---|
106 | mutable file can be modified by someone with read-write access to it. A user |
---|
107 | can have read-write access to a mutable file or read-only access to it, or no |
---|
108 | access to it at all. |
---|
109 | |
---|
110 | A user who has read-write access to a mutable file or directory can give |
---|
111 | another user read-write access to that file or directory, or they can give |
---|
112 | read-only access to that file or directory. A user who has read-only access |
---|
113 | to a file or directory can give another user read-only access to it. |
---|
114 | |
---|
115 | When linking a file or directory into a parent directory, you can use a |
---|
116 | read-write link or a read-only link. If you use a read-write link, then |
---|
117 | anyone who has read-write access to the parent directory can gain read-write |
---|
118 | access to the child, and anyone who has read-only access to the parent |
---|
119 | directory can gain read-only access to the child. If you use a read-only |
---|
120 | link, then anyone who has either read-write or read-only access to the parent |
---|
121 | directory can gain read-only access to the child. |
---|
122 | |
---|
123 | For more technical detail, please see the `the doc page`_ on the Wiki. |
---|
124 | |
---|
125 | .. _the doc page: https://tahoe-lafs.org/trac/tahoe-lafs/wiki/Doc |
---|
126 | |
---|
127 | Get Started |
---|
128 | =========== |
---|
129 | |
---|
130 | To use Tahoe-LAFS, please see :doc:`Installing Tahoe-LAFS <../Installation/install-tahoe>`. |
---|
131 | |
---|
132 | License |
---|
133 | ======= |
---|
134 | |
---|
135 | Tahoe-LAFS is an open-source project; please see the `top-level README`_ for |
---|
136 | details. |
---|
137 | |
---|
138 | .. |
---|
139 | this is really ../README.rst, but it's not included in the Sphinx build so |
---|
140 | we can't link to it normally |
---|
141 | |
---|
142 | .. _top-level README: https://github.com/tahoe-lafs/tahoe-lafs/blob/master/README.rst |
---|
143 | |
---|