Hi, Kill Your TV wrote (09 Nov 2013 16:33:56 GMT) : > On Sat, 9 Nov 2013 13:28:49 +0000 (UTC) > intrigeri <[email protected]> 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 _______________________________________________ tails-dev mailing list [email protected] https://mailman.boum.org/listinfo/tails-dev
