On Saturday 13 December 2008 18:19, Matthew Toseland wrote: > On Saturday 13 December 2008 17:40, Zero3 wrote: > > Matthew Toseland skrev: > > > Issues for the installer. Both Zero3 and nextgens seem to have decided to > > > sulk, so I'll arbitrarily decide these issues where there is deadlock and > if > > > anyone objects he can reply to this thread with a reasoned argument. > > > > I'm not sulking as in "to express ill humor or offense by remaining > > sullenly silent or withdrawn.", if that's what you mean. But I don't > > reply to mails 24/7, so I'm sorry if that is misunderstood as sulking. > > Not my intention. > > No I meant it in the sense of having an entrenched position which you are > unwilling to compromise on, threatening to leave if you don't get your way > and blaming it on the other guy. Which was true of both of you at the time. > However the debate seems to have moved on somewhat now. > > > > > 2. Whether it should run from the startup group, by the logged-in user, > rather > > > than as a system service running in its own user. > > > > > > RESOLUTION: We should continue to run Freenet as a system service. > > > > > > WHY: Freenet keeps all its config files in one place. Running it as one > user > > > and then another user would result in it breaking due to permissions > > > problems. The only ways to avoid this are 1) running it as a separate > user, > > > or 2) having per-user configuration, including the node, the Friends list > and > > > so on. IMHO 2) is utterly unacceptable, because we end up with one node > per > > > user, and updating would be tricky if not impossible. > > > > > > > Huh? Did you read my last couple of replies to nextgens? There is no > > permission breaking of any kind going on here, as I tried to explain in > > the other thread. > > I don't see how that can possibly be true. We are not just sharing the > binaries, we are updating the binaries, and we are sharing the config files: > - We want a single node, for all the users on the system, even if some are > connecting remotely and/or several users have open sessions on the same > physical screen. > - We must be able to update the freenet.ini, wrapper.conf, and the jars. In > exceptional circumstances we also need to update the update.cmd and related > files. > - If we run Freenet from the start menu, it can be started by multiple users. > Some of them may have admin rights and some will not. Who is supposed to own > the files in that case? Should we have executable files be world writable? Is > that a remotely good idea? > > > I have yet to see any kind of proof to that claim of > > nextgen's, or a least a proper explanation of these "permission > > problems" I haven't been able to reproduce at all. The argument doesn't > > even make sense, as you are giving permissions to the installed node > > files to the Freenet user atm. If there was permission problem, as > > claimed, then users wouldn't be able to access the node files from their > > regular user... > > With Freenet running under its own user, it can happily update its own files, > there is no problem. If it breaks, the user runs update.cmd, which replaces > files or makes new ones, and we have to fix the permissions so that the > Freenet user can still use them. This is usually possible, but there is no > fundamental reason why it should be, especially if the user running > update.cmd is not the user who installed it. > > One conceivable solution would be to create a Freenet group rather than user, > and deny all access to Freenet for anyone not in that group ... we could ask > the user at install time which users he wants to be in the group...
In fact, this is insane. Creating a group and making executable files writable by it and then having them run automatically by different users in that group ... NOT a good idea! Just because most Windows installations have all the users as Administrators does not mean that we should build Freenet in such a way that if it is run on a box with a sane security policy (e.g. with Power User's rather than Administrator's) it should break in wierd ways (your original proposal), or cause a major security breach (using a group). -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20081213/5d5c0c4e/attachment.pgp>
