Replies: 8 comments 7 replies
-
|
I think this can be achieved by simply not mounting any disks or devices?
If used as a Python module by default there is no disk access for example.
Having an extra option would then conflict with the existing ones and
require it to take priority, so it would be messy.
I'm generally a bit resistant to adding yet more command line options,
there are a lot of them already and each option increases the testing load.
…On Thu, 23 Jun 2022, 11:31 Rutger van Bergen, ***@***.***> wrote:
I was thinking it may be useful to add a command-line option that disables
writes to disk (files), or maybe even all devices to be on the safe side.
It could provide a rudimentary sandbox for PC-BASIC, like for running
programs that are retrieved from external sources and maybe not fully
dissected before use.
I'm happy to look into opening a PR to add this myself, but only if
opinions about the idea are favourable.
—
Reply to this email directly, view it on GitHub
<#186>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB25REV5VITVBVGRYTV2IATVQQ4GXANCNFSM5ZT27Z2A>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
Come to think of it, it may be possible to define a "preset" to achieve
this in a single call, i.e. without creating any new command line options,
just a group of settings in the config file. That could work for me
…On Thu, 23 Jun 2022, 11:36 Rob Hagemans, ***@***.***> wrote:
I think this can be achieved by simply not mounting any disks or devices?
If used as a Python module by default there is no disk access for example.
Having an extra option would then conflict with the existing ones and
require it to take priority, so it would be messy.
I'm generally a bit resistant to adding yet more command line options,
there are a lot of them already and each option increases the testing load.
On Thu, 23 Jun 2022, 11:31 Rutger van Bergen, ***@***.***>
wrote:
> I was thinking it may be useful to add a command-line option that
> disables writes to disk (files), or maybe even all devices to be on the
> safe side. It could provide a rudimentary sandbox for PC-BASIC, like for
> running programs that are retrieved from external sources and maybe not
> fully dissected before use.
>
> I'm happy to look into opening a PR to add this myself, but only if
> opinions about the idea are favourable.
>
> —
> Reply to this email directly, view it on GitHub
> <#186>, or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AB25REV5VITVBVGRYTV2IATVQQ4GXANCNFSM5ZT27Z2A>
> .
> You are receiving this because you are subscribed to this thread.Message
> ID: ***@***.***>
>
|
Beta Was this translation helpful? Give feedback.
-
|
Ok, I'll take a closer look at the preset approach, I haven't really paid much attention to it up to this point. Intuitively I would expect that the mounting approach would also prevent reading files and devices and possibly loading programs, but that I'd probably have to confirm by looking at the source code. My thinking about device mounts and read/write operations is that they are two different axes in the I/O (access) matrix. In that mental image, options/configuration concerning them would not be conflicting, but perpendicular. Anyway, I'll work on it in a feature branch in my fork. I may well ask for some feedback about my approach at different stages of development (no hard feelings if I do and you don't have the time), to not spend too much time on avenues that go against your vision. |
Beta Was this translation helpful? Give feedback.
-
|
Ok, I think I see what you mean.
Still worried that it would create another way the modal user can get
confused - drive access and setting options are the #1 and #2 cause of
questions from users, despite the time I've put into making things as clear
as possible. Unless there were a full GUI I fear this will continue to
confound some users.
Another concern is not to create an illusion of security, the last thing I
want is to make users think it doesn't matter what they run as the system
will protect them from shooting themselves in the foot. As I don't think I
can truly back up such a sense of security..
…On Thu, 23 Jun 2022, 12:00 Rutger van Bergen, ***@***.***> wrote:
Ok, I'll take a closer look at the preset approach, I haven't really paid
much attention to it yet up to this point.
Intuitively I would expect that the mounting approach would also prevent
reading files and devices and possibly loading programs, but that I'd
probably have to confirm by looking at the source code. My thinking about
device mounts and read/write operations is that they are two different axes
in the I/O (access) matrix. In that mental image, options/configuration
concerning them would not be conflicting, but perpendicular.
Anyway, I'll work on it in a feature branch in my fork. I may well ask for
some feedback about my approach at different stages of development (no hard
feelings if I do and you don't have the time), to not spend too much time
on avenues that go against your vision.
—
Reply to this email directly, view it on GitHub
<#186 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB25REURB7ZQVFZAZBA2463VQQ7UXANCNFSM5ZT27Z2A>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
I think default behaviour should be what it is now, and additional configurability should only be needed (and visible) when people explicitly decide to use it. But maybe I'm overlooking a level of unavoidable complexity that I'll discover when I look at the presets in detail. A question I already have is how we could add a "presettable" option without also introducing a command-line option; my understanding up to this point is that there is one group of options that can be set either through the command line or a config file setting? If you don't want to "advertise" it as a command-line option then we could just not mention it in the output of the -h switch. I'm not in any way suggesting we attach any security claim to this option; I'd say the text in the security section of the documentation should remain exactly what it is now. What people get is the ability to block writes to their disks and devices. If they decide to use that to limit the risk of unintended side effects then that's their decision, at their peril. |
Beta Was this translation helpful? Give feedback.
-
|
The idea of presets is just giving a name to a combination of existing
options, for example this is how the difference between GW-BASIC and Tandy
mode is defined. So my thinking was to us that to give a name to not
mounting the drives that are usually mounted. I'm not sure if it would work
as mount is a list-style option and you may only be able to grow the list
when combining presets.
But anyway that wouldn't cover mounting drives while blocking writes to
them. Maybe there should be mount options much like in Linux where you can
mount a drive read only. I've considered mount options for text encoding
and line feed mode, the code has the ability and it can be used through
Session but it's not currently exposed through the command line.
The long term strategy is for the hackier things to be exposed through the
Session API only and leave the command line / options file for more
straightforward use cases.
…On Thu, 23 Jun 2022, 14:54 Rutger van Bergen, ***@***.***> wrote:
I think default behaviour should be what it is now, and additional
configurability should only be needed (and visible) when people explicitly
decide to use it. But maybe I'm overlooking a level of unavoidable
complexity that I'll discover when I look at the presets in detail. A
question I already have is how we could add a "presettable" option without
also introducing a command-line option; my understanding up to this point
is that there is one group of options that can be set either through the
command line or a config file setting? If you don't want to "advertise" it
as a command-line option then we could just not mention it in the output of
the -h switch.
That said, documentation not being read/understood is not something I
think you can take personal responsibility for. I've ended up considering
that a fact of life.
I'm not in any way suggesting we attach any security claim to this option;
I'd say the text in the security section of the documentation should remain
exactly what it is now. What people get is the ability to block writes to
their disks and devices. If they decide to use that to limit the risk of
unintended side effects then that's their decision, at their peril.
—
Reply to this email directly, view it on GitHub
<#186 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB25REQQR63B6BJVNFG5XDLVQRT7VANCNFSM5ZT27Z2A>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
First off, I'm not offended in any way by your use of "hackier" and (less) "straightforward" with regards to my suggestion. :) Concerning mount options, if I interpret the code that processes the mount list correctly, then the last specification in the overall list concerning a specific mount wins. So if the lists are indeed concatenated then it becomes relevant in which order presets are combined. At the same time, I think it would only shift the problem to some extent, because I think one should then be able to specify the default (ro or rw), if only for the default mounts which are a great and intuitive feature. |
Beta Was this translation helpful? Give feedback.
-
|
"hackier" and "less straightforward" should of course be seen from the
context of how likely it is to throw up weird questions from people who
haven't quite read or understood the docs which I then need to figure out
how to answer :)
…On Thu, 23 Jun 2022, 19:06 Rutger van Bergen, ***@***.***> wrote:
First off, I'm not offended in any way by your use of "hackier" and (less)
"straightforward" with regards to my suggestion. :)
Concerning mount options, if I interpret the code that processes the mount
list correctly, then the last specification in the overall list concerning
a specific mount wins. So if the lists are indeed concatenated then it
becomes relevant in which order presets are combined. At the same time, I
think it would only shift the problem to some extent, because I think one
should then be able to specify the default (ro or rw), if only for the
default mounts which are a great and intuitive feature.
—
Reply to this email directly, view it on GitHub
<#186 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB25REVXJOZLSK5IXC6OXGDVQSRSJANCNFSM5ZT27Z2A>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
Hahaha, I applaud the smoothness of your save, sir. |
Beta Was this translation helpful? Give feedback.
-
|
Ok, my add-writes-enabled branch contains what I've put together yesterday and today. Of the existing Python 3 test set, I currently have:
In the next few days, I will:
In the meantime, if you feel like having a look at work in progress, now is not a bad time to do so. |
Beta Was this translation helpful? Give feedback.
-
|
Brief status update: I did cause the crashes (I touched something I didn't mean to), and the unit test failures also don't occur in the commit before my first change. I guess that's why the tests are there, eh. I'll keep you posted, obviously you may want to hold off from looking at anything until I've fixed all of the regressions. |
Beta Was this translation helpful? Give feedback.
-
|
The unit test regressions have been fixed. |
Beta Was this translation helpful? Give feedback.
-
|
28 BASIC tests failing sounds right, these are cases where we don't
reproduce GW-BASIC, mostly weird corner cases about printing to the screen
which I don't fully understand. I should probably move these tests into a
separate section so it is clear that hey are currently expected to fail.
…On Sun, 26 Jun 2022 at 11:03, Rutger van Bergen ***@***.***> wrote:
The unit test regressions have been fixed with commit 587cffd
<rbergen@587cffd>
.
—
Reply to this email directly, view it on GitHub
<#186 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB25RERYBH6AQ5IQB3XKF7TVRATHBANCNFSM5ZT27Z2A>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
Ok, that makes sense. I've just opened #188 for your review. |
Beta Was this translation helpful? Give feedback.
-
|
Just to complete the record keeping in this discussion: I've closed #188 after @robhagemans considered its merits. The feature is still present in my fork, principally for my own use. |
Beta Was this translation helpful? Give feedback.
-
I was thinking it may be useful to add a command-line option that disables writes to disk (files), or maybe even all devices to be on the safe side. It could provide a rudimentary sandbox for PC-BASIC, like for running programs that are retrieved from external sources and maybe not fully dissected before use.
I'm happy to look into opening a PR to add this myself, but only if opinions about the idea are favourable.
Beta Was this translation helpful? Give feedback.
All reactions