The `Y` drive should be (ideally) read-only

[johnnovak]

I've just deleted all commands in Y:\DOS. That's not great.

Ideally, that should be a read-only drive to prevent such mishaps from happening. This would actually necessitate adding a "read-only" mount option to the MOUNT command and the auto-mounting mechanism, but I assume this can't be too hard given CD-ROM images are read-only too.

Read-only files are handled well in programs, e.g. this is what happens when I try to delete the built-in LOADROM.COM command in DOS Navigator:

[Torinde]

Z:\ is read-only, so I would suggest moving the DOS\ folder there instead? E.g. \resources\drives\z*.* (including \resources\drives\z\DOS*.*) to be appended to the "internal" stuff presented at Z:

I always liked how Staging provides automatically a writable drive Y - actually I thought that's the whole point of having a second automatically mounted drive - Z read-only, Y writable... Yes, user can make their own X or whatever other letter, but still Y is easiest/readily available even for people who don't know they can add more letters.

[johnnovak]

I think (but @kcgen can confirm) that the reason for the existence of the Y: drive is much more mundane. The built-in tools appear on our Z: drive (these are implemented in C++ code in the emulation), but actual 3rd party DOS executables reside on the Y: drive as physical files on the host filesystem.

My preference would be too to have a single Z: drive with all the commands, but my understanding is that Y: is simply a necessity because we can't "mix" the built-in tools with actual files on the same Z: drive. Well I might be wrong, but this is my assumptions without digging into it.

Especially given that we've established that we won't include various extra 3rd party tools in the official DOSBox packages anyway, the Y: drive seems very redundant (reasons: subjective what to include, copyright issues that are next to impossible to solve with "abandonware" stuff, FreeDOS is not that great, after all, etc.)

[johnnovak]

I always liked how Staging provides automatically a writable drive Y - actually I thought that's the whole point of having a second automatically mounted drive - Z read-only, Y writable... Yes, user can make their own X or whatever other letter, but still Y is easiest/readily available even for people who don't know they can add more letters.

No, if you need any number of mountable drives, you need to mount them yourself. Same as with the C drive, really.

If you want an extra drive to be there, just in case, mount it in your global config, done. I don't think mounting an Y drive by default "just in case" as a scratch drive is great (what if I want to call it S:, or what if I don't want it at all?)

One day we will have a user manual, then people will know how to do it. But I acknowledge the user education problem you're referring to; it might not be obvious to some they can do such things.

[Torinde]

Y: is simply a necessity because we can't "mix" the built-in tools with actual files on the same Z: drive.

Maybe it was decided NOT to mix. An example where it's possible is DOSbox-X Z:\DOS that includes both 21-bytes .COM files and regular .EXE/COM files.

Anyway, a read-only option in y.conf would be nice as well (not currently possible per my cursory look at MOUNT, .conf and README)

[johnnovak]

On the other hand, the "authentic" DOS behaviour is that if you delete your DOS commands, well, that's your problem... think twice next time! 😅 Still, it would be nice if we could prevent deleting the commands we ship with.

[Torinde]

FWIW, Marking the three files read-only (on the host) results in:

[Grounded0]

Shouldn't be deletable for sure.

[johnnovak]

FWIW, Marking the three files read-only (on the host) results in:

Yeah I guess that could the least we should do.

[FeralChild64]

What’s worrying is that one can write to Y: even if -securemode is specified. If this switch is intended to stop malicious users from doing harm, this should probably be prevented.

[kcgen]

Yup, the auto-mounts [drive] conf setting will get a readonly = <bool> flag, which we'll apply to the y.conf. So then it'll always be locked down.

[johnnovak]

Admittedly, "secure mode" is not very secure... I guess exploiting some buffer-overflow attack isn't too hard, given how much low-level hackery there is in DOSBox... But I guess basic protection is better than no protection at all 🤷🏻 All I'm saying, DOSBox is a perfect attack vector for someone attacking archive.org if they're determined enough.

[johnnovak]

Yup, the auto-mounts [drive] conf setting will get a readonly = <bool> flag, which we'll apply to the y.conf. So then it'll always be locked down.

Great addition, @kcgen. What are the reasons for not just simply "mixing these commands in" to the Z drive?

[kcgen]

Z: are DOSBox internals, virtual files programmatically constructed when DOSBox comes alive.

All other drives (and files) are external files - and Y: is no different: it's contents (XCOPY and the other tools) are external files provided via resources, just like any other drives/<letter>/ mounts.

There's no custom code for Y:, and some users choose to delete Y: or augment it with their own stuff.

It's true - we could inter-mingle external files with Z: and given them some kind of special status, but that would create a third class of file: something external, with additional code to create these virtual files with real file connections, and so on. But none of that's needed (and for users, it would be more blackbox type behavior..). Right now, Y: is very tangible - it behaves just like any other drive pack.

[weirddan455]

DOSBox is a perfect attack vector for someone attacking archive.org if they're determined enough.

Not going to say it's impossible but I'm pretty sure the DOSBox player on archive.org gets run client side so it can't do much to the server. It got ported to Emscripten so it can run inside the user's browser: https://github.com/dreamlayers/em-dosbox And then from there you get the benefit of being behind the browser's sandbox so it can't do too much damage to the user's system (worst case would probably be a crypto miner or something).

[weirddan455]

In testing my file locking implementation, I must have tested some program or installer that wrote to the Y drive (looks like it was Microsoft Word for Windows from the names of these files). It resulted in me getting permission denied errors when attempting to delete my build directory for a clean build.

daniel@debian:~/code/dosbox-staging$ rm -rf build
rm: cannot remove 'build/debug/resources/drives/y/~MSSTFQF.T/SETUP.STF': Permission denied
rm: cannot remove 'build/debug/resources/drives/y/~MSSTFQF.T/WINWORD6.INF': Permission denied
rm: cannot remove 'build/debug/resources/drives/y/~MSSTFQF.T/WORD_BB.DLL': Permission denied
rm: cannot remove 'build/debug/resources/drives/y/~MSSTFQF.T/WWSETUP.TTF': Permission denied
rm: cannot remove 'build/debug/resources/drives/y/~MSSTFQF.T/ACMSETUP.EXE': Permission denied
rm: cannot remove 'build/debug/resources/drives/y/~MSSTFQF.T/MSSETUP.DLL': Permission denied
rm: cannot remove 'build/debug/resources/drives/y/~MSSTFQF.T/_MSSETUP.EXE': Permission denied
rm: cannot remove 'build/debug/resources/drives/y/~MSSTFQF.T/ACMSETUP.HLP': Permission denied
rm: cannot remove 'build/debug/resources/drives/y/~MSSTFQF.T/_MSSETUP._Q_': Permission denied
rm: cannot remove 'build/debug/resources/drives/y/~MSSTFQF.T/ODBCINST.DLL': Permission denied
rm: cannot remove 'build/debug/resources/drives/y/~MSSTFQF.T/MSCPYDIS.DLL': Permission denied

Issue was that the directory it created was did not have write permissions set. I was able to delete them after doing a chmod

daniel@debian:~/code/dosbox-staging$ ls -lh build/debug/resources/drives/y
total 4.0K
dr-xr-xr-x 2 daniel daniel 4.0K May 25 22:01 '~MSSTFQF.T'
daniel@debian:~/code/dosbox-staging$ chmod 755 build/debug/resources/drives/y/~MSSTFQF.T

So maybe this is another reason to make this drive read-only. Was not expecting any programs to create files here.

[Grounded0]

Yeah this definitely should be read-only.

[weirddan455]

I'll work on implementing this. In a lot of installs of Staging, the Y drive is going to be read-only on the host anyway. Ex. Fedora installs the Y drive to /usr/share where a normal user will not have write access.

I believe this is what needs to happen:

1. Implement a readonly flag for localDrive. This already exists for fatDrive. If readonly is set, throw a DOSERR_ACCESS_DENIED on file writes, creation, and deletions.
2. Implement a -ro flag for the mount command. This already exists for imgmount but not for mount.
3. Add a readonly config setting to [drive]. This will simply pass the -ro flag to mount.
4. Add readonly = true to contrib/resources/drives/y.conf so it is read-only by default. Users can of course change this if they want.

This will also let users set any localDrive to be read-only if they want.

[johnnovak]

Sounds like a solid plan @weirddan455. 🥳

May I also draw your attention to the Mounting improvements megaticket (https://github.com/dosbox-staging/dosbox-staging/issues/3552) this ticket is part of 😉 😉

[interloper98]

Lock it down! really appreciate this @weirddan455.