[openbeos] Re: OBOS Security
- From: "Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Sat, 10 Aug 2002 18:58:45 CEST (+0200)
> >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?
I guess I still don't get your point. Of course I'd like to have the
possibility of running GUI applications remotely. And as I tried to
outline in my last mail, it doesn't seem to be that big a problem,
merely support of redirecting communications to servers over network.
Maybe I miss something very basic here.
> We can already allow logins and such with SSH/telnet.
Unless I missed the release of a SSH daemon for R5, I can't. But that's
another story.
> Basically, my objections are this:
> 1) No one would really want to use it, since it defeats the purpose
You are referring to the setting without remote GUI support, I guess.
> 2) It would require us to become a *lot* more internally security
> concious
Absolutely.
> 3) API changes would have to be made, re 2 above
Agreed.
> 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).
Agreed too.
> 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.
The latter is the point: If I can log into this machine with SSH at the
same time another uses is logged in, then there must be some security
to protect both of them and the system from each other. Otherwise I
doubt that this solution has a chance to be accepted.
> 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.
I would consider usability and benefits technical reasons as well. If
something is not usable or has very little benefits then there is not
much reason to implement it. In case of multi-user I see benefits, and
usability has to be examined, though I don't expect problems there.
> 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.
I'm the last one who would advocate multi-user as the highest priority
goal. HWOPL, tons of drivers and certainly a whole bunch of other
features certainly have higher priority.
What I was actually trying to say with that the amount work doesn't
really count is, that this feature shouldn't be categorically excluded
just because it seems to -- and undoubtly will -- be a lot of work.
Nevertheless I'm absolutely sure, it is less work than implementing
OBOS R1, and can thus be considered feasible.
To sum my position up: I'd like to see a multi-login/multi-user on the
ToDo list, meaning that once we come to a point where higher priorized
goals are reached, there would be a fair and thorough analysis on these
concepts resulting in decision.
> >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 :-)
I guess, that's a broad hint, that people start to get annoyed by this
discussion. :-)
I rather go back to coding...
CU, Ingo
Other related posts:
