OSDev.org

Are common dialogs such as the open file dialog, print dialog, etc. typically implemented in services or libraries?

Some advantages of implementing these dialogs in a service:

• Every program will use the latest version of the dialog, even if the program is out dated.
• The dialog can have permission that the end program doesn't. For example, the Open File dialog can view the contents of directories that the program can't.

AndrewAPrice wrote:Every program will use the latest version of the dialog, even if the program is out dated.

Dynamically linked libraries provide that facility.

The dialog can have permission that the end program doesn't. For example, the Open File dialog can view the contents of directories that the program can't.

Is that a good thing? If the program isn't allowed to view the contents of a directory should it be allowed to do so via an external service?

iansjack wrote:

The dialog can have permission that the end program doesn't. For example, the Open File dialog can view the contents of directories that the program can't.

Is that a good thing? If the program isn't allowed to view the contents of a directory should it be allowed to do so via an external service?

Yes. In my OS, applications won't touch anything outside of their own directories or shared library assets without permission. Certainly not a user's potentially sensitive or otherwise valuable files! Rather than prompt "is X allowed to open this directory?" while the user is browsing what to open/save, they could have full access to their personal files in the Open/Save dialog, and the dialog could tell the VFS to grant this application access to this file just this once. The external service won't let the program see anything else in the directory - it just returns a path that the program is allowed to touch.

AndrewAPrice wrote:

iansjack wrote:

The dialog can have permission that the end program doesn't. For example, the Open File dialog can view the contents of directories that the program can't.

Is that a good thing? If the program isn't allowed to view the contents of a directory should it be allowed to do so via an external service?

Yes. In my OS, applications won't touch anything outside of their own directories or shared library assets without permission. Certainly not a user's potentially sensitive or otherwise valuable files! Rather than prompt "is X allowed to open this directory?" while the user is browsing what to open/save, they could have full access to their personal files in the Open/Save dialog, and the dialog could tell the VFS to grant this application access to this file just this once. The external service won't let the program see anything else in the directory - it just returns a path that the program is allowed to touch.

I like it! That would definitely have to be a system service, that the OS and the user can trust, and is similar to how WIndows handles Ctrl-Alt-Delete to provide a trusted login service. Nothing but Windows can trap C-A-D, so the user knows the resulting security screen can be trusted.

How would that map to something like open(), though?

Would it be something like running each process in their own VFS jail, mapping the file selected by the user into the VFS visible to the process, and returning the name of the mapped file to the process?

How about temporary files?

How about patterns like writing a new content to a temporary file, then atomically renaming the new file over the old file to replace it? Perhaps some API to write a new version of a file, with commit and rollback semantics to either replace the existing file or abort replacing the file.

thewrongchristian wrote:I like it!

Thanks!

How would that map to something like open(), though?

Would it be something like running each process in their own VFS jail, mapping the file selected by the user into the VFS visible to the process, and returning the name of the mapped file to the process?

Yes, each process (actually grouped by the applications/programs, e.g. all instances of GIMP) can just access their own directories (via /Application/ - I'm not following POSIX) and the libraries they depend on. For anything else, the program needs to be granted permission.

In practice, open() is implemented via an RPC to my VFS server. My microkernel attaches the caller's pid to all RPCs. So the VFS sees "GIMP is trying to read /abc/def/hij.jpeg". When the VFS sees the path starts with "/Application/" it treats it like any other mount point, but this one is specific to the running process (it can ask around to find out what directory it was launched from and substitute "/Application/" with that directory.)

Then it's a question of "Can GIMP open <full path>?" I'll keep a set of fully resolved file paths (and fully resolved directories) that an application can touch. And we can then check if this file or one of its ancestor directories is in this set. If it is, we can open the file, if not, we can prompt a dialog:
"GIMP is trying to open /abc/def/high.jpeg.

Can GIMP have access?
[Yes] [No]
Remember this choice for:
[o] Just this once
[ ] One hour
[ ] Always"

If the user picks "no" we return an error. And so, the system file dialog would be an easy way to grant "just this once" access to a specific file and we can skip the above prompt when we follow up with open() because we know the user explicitly selected that file.

How about temporary files?

How about patterns like writing a new content to a temporary file, then atomically renaming the new file over the old file to replace it? Perhaps some API to write a new version of a file, with commit and rollback semantics to either replace the existing file or abort replacing the file.

I haven't thought too much about temp files. Maybe we can create a /Temp/ directory that is isolated to each program (e.g. all instances of GIMP will see the temp /Temp/ dir, but it might resolve /Memdisk/Temp files/<program>/. If needed, a program could grant another program's access to it's temp files.) I'll tackle this when I encounter a use case that needs it

Same with my OS, the File Open/Save dialog is implemented as a system service, but it returns a file handle directly. The system also provides automatic menu items for Open, Save, Save As and the MRU list. Thus, programs mostly do not deal with path strings when handling user files. Instead of getting a file handle, a program could also get a path handle that can be used to open, rename or create a file later, or one can get a relative path string given a path and root directory.

As for what OS functions are implemented in an user space library, or in the kernel, or by communicating with aliens on the moon, it's all the same to the program, it just calls into a set of jumps provided by the loader identified by a known system interface ID.

Gigasoft wrote:but it returns a file handle directly.

What is the advantage of this? Is there a benefit to obscuring the path of the file to the program opening it?

Sometimes in Sublime I work with multiple files of the same name and hover my mouse cursor over the tab to see the full filename. We'd loose this unless you opened the directory as a "workspace" and the program had a path handle and then could show you relative paths within the workspace. So, maybe not a big deal.

As for what OS functions are implemented in an user space library, or in the kernel, or by communicating with aliens on the moon, it's all the same to the program, it just calls into a set of jumps provided by the loader identified by a known system interface ID.

Exactly. I'll provide a C++ API. The caller shouldn't care how it works as long as it just does.

Well, the advantage is that I don't need to keep a separate list of granted file permissions elsewhere.

As for identifying a file to the user, it could be done by letting the program use the user's root directory as a reference but without any access rights, or I could have a separate API to get an user friendly string for a path. I already have similar functionality for opened files, where it will return something like "/some/filename on Partition 1 on CT500MX500SSD1", but this is mainly intended for things such as system error messages and for debugging. If one is paranoid about spyware harvesting information from these strings, it might not be a good idea to provide this information directly to applications, but I suppose one could have it displayed via system managed UI elements such as tab controls and tooltips as I already do with the menus.

AndrewAPrice wrote:

Gigasoft wrote:but it returns a file handle directly.

What is the advantage of this? Is there a benefit to obscuring the path of the file to the program opening it?

A very strong means of protection is to not even make it possible to construct a reference to an object that a process does not have permission to access: this is basically what you're doing at the hardware level with paging.

Rather than having "/Application" as a subdirectory of /, you could just give each process its own /, containing just the resources it needs, and then if an application has permission to see every file on the system, you might have "/system" as a special mount for that application. An application that doesn't have /system in its filesystem wouldn't, in principal, know if there *is* anything on the system beyond its own /, or if it's running on a stripped-down OS that is just running that one application and really only contains the files that the application can see.

You don't need to only use completely opaque file handles, but it doesn't need to be possible for an arbitrary process to be able to construct system-absolute paths. (Think of this as an extreme form of the chroot mechanism).

Sometimes in Sublime I work with multiple files of the same name and hover my mouse cursor over the tab to see the full filename. We'd loose this unless you opened the directory as a "workspace" and the program had a path handle and then could show you relative paths within the workspace. So, maybe not a big deal.

You could do this by having the application make a call "DisplayUserPath()" on mouseover that takes an application path or a file handle and tells the windowing system to display the path that the user would know the file by. This itself doesn't need to be an absolute path. If the user isn't an administrator, then you might want to have them see their home directory as /, and then any other directories they are given access to might appear as mounts somewhere under /.