Date: Tue, 14 Apr 2009 13:58:26 -0400 From: "Mikhail T." <mi+thun@aldan.algebra.com> To: Iain Hibbert <plunky@rya-online.net> Cc: "freebsd-bluetooth@freebsd.org" <freebsd-bluetooth@freebsd.org> Subject: Re: RFC: obexapp - virtual root folder for each device Message-ID: <49E4CEC2.6060505@aldan.algebra.com> In-Reply-To: <1239725723.321671.1132.nullmailer@galant.ukfsn.org> References: <bb4a86c70904131640n7cf471c0o7a56a43d722a90e1@mail.gmail.com> <49E3DB35.4030601@aldan.algebra.com> <bb4a86c70904131909k44aba88dk126d25a4f1fc3744@mail.gmail.com> <49E41DBB.5090805@aldan.algebra.com> <1239725723.321671.1132.nullmailer@galant.ukfsn.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Iain Hibbert ΞΑΠΙΣΑΧ(ΜΑ): > I agree too, its not good to run a daemon (that can be accessed over a > radio link and create/modify files no less) as root. > Both proposals being discussed currently presume the original daemon running as root, dropping privileges only after forking. Whatever mechanism is devised to avoid that, would be applicable to both, so lets put this part "outside of the parentheses" :-) > If you did that, it would I think be better to have the bdaddr mapping in > a config file. Symlinks are too much trouble. On the other hand, I'm not > keen on config files either :) > Config-files are a far greater "evil". Their maintenance by more than one person (or one with more than one terminal) requires locking, etc. -- for no additional benefit. Just use `ls -l' instead of `cat'... Symlinks (be they "broken" or not) can be maintained atomically and are thus superior. And each record keeps the timestamp and other useful info... >> But what about dropping camera's pictures and videos? People would certainly expect to be able to do that straight from their devices (rather than by running a client of some sort), and find the files somewhere under their home directories (perhaps in ~/Desktop). >> > > Do you want to send pictures to your account when your wife is logged in, > or does she want to when you are logged in? I don't see, how this is relevant. Everything, I and Maksim, are talking about is equally applicable even to a completely headless server. In my earlier e-mail (responding to Maksim), I give an example of a server set up to accept media uploads from multiple photographers (think of the guys with giant lenses around a football field, wirelessly pushing their snaps to the single box, from which editors pick them up for broadcasting/publishing nearly real-time) -- nobody needs to be logged-in to the box itself for that to work... > I don't know what prior art is there, but it seems to me that (as I said before) the person logged in at the console owns the machine and should receive files being sent. I don't know, what you mean. The two of us (and the babysitter, BTW) each have our own X-session, which are all started by KDM on demand. Ctrl-Alt-F9 is, usually, me, Ctrl-Alt-F10 -- the better third, and Ctrl-Alt-F11 -- whoever else needs access to their e-mail... None of this is relevant, though, I think... > For this reason, Bluetooth cannot properly be a multi-user link unless all the users trust each other (while Alice is sending files to the computer, Bill could be checking her phone log) so I don't see a problem with having all the files in a master directory owned by the same user (but setting the default path per remote device seems a good compromise) > Yes, it is a good compromise. And it can go one step further towards convenience (without compromising security), by using not just the device-specific PATH, but also the device-specific UID/GID... Yours, -mi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49E4CEC2.6060505>