The new ImageDecoder service (available for members of "image" via
/tmp/portal/image) allows you to decode images in a separate process.
This will allow programs to confidently load untrusted images, since
the bulk of the security concerns are sandboxed to a separate process.
The only API right now is a synchronous IPC DecodeImage() call that
takes a shbuf with encoded image data and returns a shared buffer and
metadata for the decoded image.
It also comes with a very simple library for interfacing with the
ImageDecoder service: LibImageDecoderClient. The name is a bit of a
mouthful but I guess we can rename it later if we think of something
nicer to call it.
There's obviously a bit of overhead to spawning a separate process
for every image decode, so this is mostly only appropriate for
untrusted images (e.g stuff downloaded from the web) and not necessary
for trusted local images (e.g stuff in /res)
Port the WebContent service to the new MultiInstance mechanism that
Sergey added. This means that every new WebContentView gets its very
own segregated WebContent process.
The "WebContent" service provides a very restricted instance of LibWeb
running as an unprivileged user account. This will be used to implement
process separation in Browser, among other things.
This first cut of the service only spawns a single WebContent process
when someone connects to /tmp/portal/webcontent. We will soon switch
this over to spawning a new process for each connection.
Since this feature is very immature, we'll be bringing it up inside of
Demos/WebView as a separate demo program. Eventually this will become
a reusable widget that anyone can embed and easily get out-of-process
web content in their GUI.
This is pretty, pretty cool! :^)
We were getting a little overly memey in some places, so let's scale
things back to business-casual.
Informal language is fine in comments, commits and debug logs,
but let's keep the runtime nice and presentable. :^)
Now that we have SystemServer that can (re)spawn the Shell, we don't need a
separate server just for that.
The two shells (on tty0 and tty1) are configured to only be started when booting
in text mode. This means you can now simply say boot_mode=text on the kernel
command line, and SystemServer will set up the system and spawn a comfy root
shell for you :^)
It will listen for clipboard content changes in the backgroud. Once you click
on its icon, it will pop up a window listing all recorded clipboard contents.
You can then double-click on an item to copy it again.
This commit moves the clipboard from WindowServer into a new Clipboard
service program. Clipboard runs as the unprivileged "clipboard" user
and with a much tighter pledge than WindowServer.
To keep things working as before, all GUI::Application users now make
a connection to Clipboard after making the connection to WindowServer.
It could be interesting to connect to Clipboard on demand, but right
now that would necessitate expanding every GUI app's pledge to include
"unix" and also unveiling the clipboard portal, which I prefer not to.
Step one of moving DesktopServices::open handling out of process. This
makes it easier to do things like read in associations for which program
opens which files or protocols. This gives users the ability to modify
the associations without having to rebuild :^)
The ResourceGraph menu applet now supports a few command line options:
--cpu / -C to display a CPU usage graph
--memory / -M to display a memory usage graph
--name / -n to set a name which is used to order applets
--color / -c to set the graph color (supports anything
Gfx::Color::from_string() understands)
The SystemServer.ini and WindowServer.ini config files have been updated
to spawn and show two ResourceGraph menu applets, one for CPU usage
(green) and one for memory usage (cyan) - this matches the colors in the
SystemMonitor graphs.
The plan is to extend what currently is known as "CPUGraph" and let the
SystemServer spawn multiple instances of it - which then can show memory
or network usages as well :^)
Simply renaming the applet is the first step.
Prior to this, we ran the DHCP client as a high-priority service, but
making the system feel laggy "for some network stuff" is not the
greatest of ideas :^)
Services can now have their initial working directory
configured via `SystemServer.ini`.
This commit also configures Terminal's working directory
to be /home/anon
I probably would've done INI config removal in another commit, but it
fit well here because I didn't want to pledge wpath for SystemMenu if I
didn't need to.
Frankly, that's something that I think should be done: allow ConfigFile
to be used read-only.
This patch adds NotificationServer, which runs as the "notify" user
and provides an IPC API for desktop notifications.
LibGUI gains the GUI::Notification class for showing notifications.
NotificationServer is spawned on demand and will unspawn after
dimissing all visible notifications. :^)
Finally, this also comes with a small /bin/notify utility.
This was actually rather painless and straightforward. WindowServer now
runs as the "window" user. Users in the "window" group can connect to
it via the socket in /tmp/portal/window as usual.
This is probably not the final design we'll want for this, but for now
let's run the HTTP client code as a separate user to reduce exposure
for the standard "anon" user account.
Note that "protocol" is also added to the "lookup" group, in order to
allow ProtocolServer to contact LookupServer for DNS requests.
LookupServer now runs as lookup:lookup, allowing connections from other
members of the "lookup" group.
This is enforced through file system permissions by having the service
socket (/tmp/portal/lookup) be mode 0660.
Now the LookupServer program can't overwrite other people's files if it
starts misbehaving. That's pretty cool :^)
This patch introduces the second MenuApplet: Audio. To make this work,
menu applet windows now also receive mouse events.
There's still some problem with mute/unmute via clicking not actually
working, but the call goes from the applet program over IPC to the
AudioServer, where something goes wrong with the state change message.
Need to look at that separately.
Anyways, it's pretty cool to have more applets running in their own
separate processes. :^)
For services explicitly configured as lazy, SystemServer will now listen
on the socket and only spawn the service once a client attempts to connect
to the socket.
