[tahoe-dev] multi-user tahoe node suggestions
Jody Harris
imhavoc at gmail.com
Wed Jan 13 20:34:33 PST 2010
This (i.e. one instance, multiple users, set up) needs to be documented in
the usage doc. This question has been running back and forth across my mind
for a week.
j
----
- Think carefully.
- Contra mundum - "Against the world" (St. Athanasius)
- Credo ut intelliga - "I believe that I may know" (St. Augustin of Hippo)
On Wed, Jan 13, 2010 at 12:26 PM, Brian Warner <warner at lothar.com> wrote:
> (just adding to what Zooko said..)
>
> Kyle Markley wrote:
> > What are the recommended methods for setting up a tahoe node to be
> > used by multiple users on a host, without using root?
>
> Yeah, don't run the tahoe node as root.. it has no need for that. We
> actually have an unfinished ticket to make it complain if it is run as
> root.
>
>
> > How then do I best enable other users on the same machine to use the
> > same tahoe node? (Is that even what I really want?)
>
> From a reliability point of view, there's not much value to running more
> than one storage node per computer (or one per disk spindle, depending
> upon how well the system tolerates disk failures). So if you're enabling
> storage, I'd certainly stick to having just one node. Even if you aren't
> providing storage, there's a (linear) performance hit to running
> multiple nodes.. each will use separate memory, separate network
> connections, etc.
>
> The main disadvantage to having multiple users sharing a node is
> security. All users are vulnerable to anyone who can control the node
> (probably you, in this case). With a few code changes, you could capture
> their filecaps, read their documents, and modify them undetectably. If
> you're the host admin, you have all those powers already, so it wouldn't
> matter.
>
> > Alternately, what are the (dis)advantages of creating a dedicated user
> > account to run the tahoe node?
>
> I'd create a separate account to run the node, if only to make it easier
> to keep track of how much CPU and disk space it's using, and to limit
> the damage to your own account in the unlikely case that some major bug
> in Python or Tahoe allows an attacker to compromise the tahoe node
> (buffer overflow or something).
>
>
> Personally, I'd run a single node on my box, in a new dedicated account
> (named "tahoe" or "tahoe-prodgrid" or something) and make it available
> as a service for my other users. I might set it to listen on
> web.port="tcp:3456:interface=127.0.0.1" to restrict its use to local
> users and their CLI tools. And then I'd tell my users to set up and test
> their CLI tools by doing the following:
>
> mkdir ~/.tahoe
> mkdir ~/.tahoe/private
> echo "http://127.0.0.1:3456/" >~/.tahoe/node.url
> tahoe create-alias tahoe:
> echo "yay" |tahoe put - tahoe:yay.txt
> tahoe get tahoe:yay.txt
>
>
> cheers,
> -Brian
>
>
> _______________________________________________
> tahoe-dev mailing list
> tahoe-dev at allmydata.org
> http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://allmydata.org/pipermail/tahoe-dev/attachments/20100113/c369d88b/attachment-0001.htm
More information about the tahoe-dev
mailing list