source: trunk/docs/about.rst

Last change on this file was 4723af6, checked in by Brian Warner <warner@…>, at 2017-06-06T10:20:49Z

LAFS now stands for "Least-Authority File Store" rather than "Least-Authority File System". refs #2345

Signed-off-by: Daira Hopwood <daira@…>

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