id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc	launchpad_bug
219	permissions on files containing secrets	zooko	zooko	"A unix user wanted a tahoe node to belong to a set of unix accounts instead of a single account, and he used unix groups to set up the permissions, but tahoe foiled him by executing ""chmod(secretfile, 0600)"" on several secret files.

http://allmydata.org/pipermail/tahoe-dev/2007-December/000254.html

There are a couple of ways that we could enable this kind of usage without exposing the secret files by default to ""other"".  One is just change the constant in our chmod lines to 0660.  Nowadays, the default group tends to be quite small -- typically just the same user, so that should be safe.

Oh, I just realized that the way we are doing this is a race condition.  An attacker could read the contents of the secret file after we've written it but before we've chmodded it.  Oops.  (I checked, and we do ''not'' currently make sure to chmod the file before writing secret data into it in every case.  This should be fixed immediately.)

Perhaps we should chmod the tahoe basedir itself instead of specific files.  That would solve the race condition, and perhaps make it slightly easier for unix users to adjust the permissions manually.

Alternately, we could create a subdirectory inside the basedir named ""private"".  This appeals to me because I like to share information which ''isn't'' secret -- the other parts of the tahoe config and state can be examined by other users for their edification.  It also helps document to the user which files they ought to be more careful with.

"	defect	closed	major	0.7.0	code-nodeadmin	0.7.0	fixed	security access control unix