Hi,
Kill Your TV wrote (09 Nov 2013 16:33:56 GMT) :
> On Sat, 9 Nov 2013 13:28:49 +0000 (UTC)
> intrigeri <intrigeri@???> wrote:
>> 4. I read this:
>> > * relaxed permissions so that both the i2psvc user and the
>> > i2psvc group have access
>> Access to what, and why is it useful / needed for?
>> I assume this documents this change:
>> > # Loosen wrapper permissions so that the amnesia user (who'll be
>> > added to the i2psvc group) has access sed -i
>> > 's|^.*\(wrapper.*umask=\).*|\10007|g' "$WRAPPER"
>> and:
>> > # * insecure files: Enabled. This means that permissions will
>> > not be forced # to 700 for the i2psvc user, giving i2psvc
>> > group members access.
>> ... that don't tell me much either.
> It was intended to give access to /var/lib/i2p to the standard amnesia
> user so that s/he could make changes without needing 'sudo' By default
> the Java Service Wrapper is configured thusly:
> # Set permissions used when creating files
> # See http://wrapper.tanukisoftware.com/doc/english/prop-umask.html
> # for a detailed explanation of these settings.
> wrapper.umask=0022
> wrapper.java.umask=0022
> wrapper.logfile.umask=0077
> This effectively means that the i2psvc user is the only one with
> read/write access. Others, including the i2psvc group, cannot write
> to /var/lib/i2p. Potential problems with this default set-up for a
> Tails user who does not set a password prior to logging in:
> - If a Tails user tried to start I2P and it failed for some
> reason, s/he may be advised to look in /var/log/i2p. Due to the default
> umask set, the amnesia user cannot access it.
> - If a Tails user (for whatever reason) decided to download an
> I2P-internal torrent, any such files would be lost.
> - If a Tails user wanted to set up an 'eepsite' (be it temporarily to
> share something quickly or something a bit more long term once we
> have persistence enabled), s/he wouldn't be able to access that
> folder
OK, thanks for making the usecases clear :)
Let's see if and how we can support them in a reasonable way.
>> A further commit reads "Add the amnesia user to the i2psvc group",
>> "This will allow the standard Tails user to access the I2P config
>> directory." Same question: what is it useful for? Does this *only*
>> adds access to that directory, or does it gives the desktop user
>> other credentials as a side effect? If access to that directory is
>> really needed, and only that, perhaps we could use an ACL instead?
> The only extra access /should/ be only to access that directory without
> requiring admin access being set upon logging in.
Has read-write access to that directory other consequence?
I mean, if I understand it clearly, the proposed umask means that the
desktop user has full r/w access to /var/lib/i2p/i2p-config/, so they
can essentially reconfigure I2P and interfere with basically every
piece of data the I2P programs trust, no?
If I'm correct, we have a problem. Doesn't I2P support some config /
daemon state / user data separation?
>> 5. I read this:
>> > * Boostrap through 127.0.0.1:8118
>>
>> This is an important change to how Tails has been using I2P until
>> now. If our brand new I2P maintainer says it's better to have it go
>> through Tor, I'm very happy. Is it now *entirely* going through
>> Tor, that is, can we drop the firewall exception that allows I2P to
>> go out in the clear, and update the design doc accordingly? Or is
>> it only the bootstrap step that goes over Tor?
> Only the initial reseeding/bootstrapping would happen over Tor.
OK, then:
* Why the change to make it bootstrap over Tor?
* Why not have the whole I2P thing to go over Tor?
>> Also, is it possible to use the Tor SOCKS proxy, rather than going
>> through polipo? (We're at the point we can almost ditch it
>> entirely, and stop shipping a HTTP proxy in Tails, so adding
>> a usecase for it makes me sad.)
> Using a SOCKS proxy isn't possible yet but I can file a wishlist bug
> for it.
Yes, please.
Cheers,
--
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
