[DGD] Kernerl security without guest programmers

[bart at wotf.org]

I think both are valid approaches. What I suggest comes down to a try catch
approach, which lets you handle a whole bunch of situations in one go, but
still requires you explicitly think about, and do work to not make the access
check cause a runtime error. To me this seems mostly a difference in style.

Bart.

On Tue, 31 Jan 2017 14:56:57 -0800, Raymond Jennings wrote
> Way I see it, if you're assuming privileges, it should be like an assert
> and cause a runtime error.  If you expect that it might fail, then 
> you should explicitly test privileges first.
> 
> On Tue, Jan 31, 2017 at 2:30 PM, <bart at wotf.org> wrote:
> 
> > On Tue, 31 Jan 2017 13:21:15 -0800, Raymond Jennings wrote
> >
> > > > object find_account(string user)
> > > > {
> > > >   if (! SYSTEM())
> > > >     return nil;
> > > >
> > > >   ...
> > > > }
> > > >
> > >
> > > For this I vastly prefer causing a runtime error.
> > >
> > > In my opinion (tm), code that fails silently when it tries to do
> > something
> > > it isn't supposed to be doing in the first place needs to be fixed, and
> > > flagging an error helps weed these cases out.
> >
> > I'm of the same opinion, and for example Gurbalib's require_priv() afun
> > causes
> > a runtime error when the required privilege is not met.
> >
> > Code calling a privileged method can always catch those runtime errors if
> > they
> > are expected, so the lpc code can handle them nicely (think of giving nice
> > feedback to a user mistyping a path in a file command for example).
> >
> > Bart.
> > --
> > http://www.flickr.com/photos/mrobjective/
> > http://www.om-d.org/
> >
> > ____________________________________________
> > https://mail.dworkin.nl/mailman/listinfo/dgd
> >
> ____________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd


--
http://www.flickr.com/photos/mrobjective/
http://www.om-d.org/