[openbeos] Re: OBOS Security
- From: "Michael Phipps" <mphipps1@xxxxxxxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Sat, 10 Aug 2002 10:44:51 -0400
>Ingo wrote:
>> I must have missed this half. Any examples?
Sure. Unless you have a VNC (or X, if you prefer) type system in place,
Game Kit, Interface Kit, Media Kit, OpenGL Kit and (really) Translation Kit
are useless for multi-user. Oh, and the Device Kit, too.
That is a bug hunk of API. Basically, without VNC/X, BeOS in a multi-user
(again - I mean accessing your BeOS machine from another computer, not
having 2 people use the same computer with different accounts) setting
is basically the same as a stripped down BSD or something. Most of the C++
api goes away, leaving you with Posix plus a little. Who wants that?
We can already allow logins and such with SSH/telnet.
Basically, my objections are this:
1) No one would really want to use it, since it defeats the purpose
2) It would require us to become a *lot* more internally security concious
3) API changes would have to be made, re 2 above
4) It complicates the source code (any change does; this has to be weighed
against what it offers - there is no such thing as a free lunch).
Now, *INSTEAD*, what I think might be interesting would be a package
for Linux/BSD that is designed for hosting multiple BeOS machines. For the
university setup that people talked about. It might consist of BFS for Unix
and/or maybe an app that stores attributes and such in seperate files, so that
people could use a Linux/BSD file server without losing attributes. Maybe user
authentication could come from the *nix box as well. Something like that would
solve at least some of the problems that people have. That plus SSH would
be a major win for corporate/Uni/etc situations.
>> IMHO technical arguments alone should be the guide to the decision
>> whether or not true multi-user will be implemented. The fact that it
>> will be a lot of work doesn't really count, at least it sounds a bit
>> schizophrenic in a group coding an OS. Things like a serious hit to
>> media performance was one -- before it is properly analyzed I won't
>> belief this though -- or the nessecity of breaking binary
>> compatibility
>> (in case it should be maintained at that point) was another one.
>
>I completely agree with this one.
I agree that Technical Reasons have to be a major factor. But I think that to
look
at things from a usability and benefit standpoint has to weigh in, too.
Amount of work *has* to matter. Open source != infinite pool of devs. Oh, do I
wish
otherwise. ;-) But it isn't. And we really need to prioritize what we do, post
R1. There
are an infinite number of changes that we *can* make. Should depends on a lot
of things.
Technical reasons are certainly key. But (as an example) adding C64 gfx
translators would
be *way* further down my list than, say, PNG translators. Or, say, HWOGL is
higher than
multi-user. IMHO.
>And that could also be used as the final word on this: we'll do it as
>good as it is possible, later in R2 :-)
>
>What we should do now, however, is to encourage developers to make sure
>their apps won't break in a multi-user environment. ATM this mainly
>means the use of find_directory() over hard-coded solutions.
Sure. Absolutely. And this is important, too, for multiple logins
(non-simultaneous) on the same box.
Which I think that we all recognize as a critical feature.
Other related posts:
