[gold-devel] Here we go, folks
Justin Hibbits
jrh29 at alumni.cwru.edu
Sun Mar 11 19:20:22 EDT 2007
On Mar 3, 2007, at 11:33 AM, Justin Hibbits wrote:
> Now, the time I've been trying to bring for the last 2 years: What
> do we want, what are our goals, and what do we need to obtain them?
>
> Here's what I know so far:
>
> - Object system (no files, just objects with forks, or whatever) --
> have to flesh the behavior of this out.
> - authd is a 'trusted' application, it has the following purposes:
> - Spawn 'init'
> - Spawn session login manager
> - Spawn authentication handlers
> - Spawn session manager
> - Handle authentication and spawning processes under other users
> - Shutdown the system
>
> - authd doesn't use or know about named objects (URI-types), and
> should never know, for security reasons.
>
> - I think we should break libSystem into two parts: libSystem and
> libUser, to provide core system interfaces and user-only interfaces.
>
> Now, we need to decide the following things:
> - What do we want?
> - How do we get there?
>
> Specifically:
> - What does LSD provide, and consume?
> - How does the system start up?
> - How does a user session work?
> - What do we provide to users to get their work done?
>
>
> That is all,
> - Justin
Here's what I have from my own thoughts:
We're going with PowerPC as our target architecture, using
OpenFirmware as the boot base, since it makes things simpler to get
booting. As soon as possible we get into a graphical environment, so
we start authd as soon as it can access disk, and start the Golem
server for a nice graphical boot environment. Of course, we log
everything, using the log interface (meaning that has to be started
early as well, or stored in a queue somewhere to log).
Authd is a cool program, managing session separation, authentication,
authorization, and basic security. We're going with a multi-tiered
approach, using User/System separation as well as Local/Network
context separation, along with other security measures. All of these
will be accessible from programs through some interface (to be
determined, when we do lower-level design). I want to have role-
based ACLs as well, maybe in the future MAC/MIC (but can't now,
because it conflicts directly with my work at BAE), and everything
would be tagged with a role, or set of roles, from local 'filesystem'
objects to IP ports, to the IP stack itself. More discussion on this
later. Authd would be two parts: Userspace and kernel space. This
is to allow some things to be quickly determined by the kernel while
other things (spawning processes, etc) would be done purely in user
space, to maintain the integrity of the system.
As I stated above, Gold will be primarily a graphical environment,
but will have command interfaces available to any and every program,
with no design for the specific program needed in order to support
this. Like most UNIX systems, there will be a log daemon, and a user
interface to read, parse, and search the logs. The log daemon itself
will take care of formatting, etc, programs would only have to send a
string object to the log daemon, representing the message, no time/
datestamps, since those would be handled by the log daemon for a
consistent logging format. The complete design of this daemon should
be discussed, or I will design it myself using a 'makes sense'
design, rather than 'most flexible'.
One thing that's been discussed and mostly rejected, or reluctantly
accepted, is a central configuration system. However, a central
configuration system would allow for configuration of both system and
user settings in a consistent manner. I'm not saying that we would
model it directly on the Windows registry, but it would be one
consistent interface that appears centrally managed, but would
actually consist of several files (system, user, application
settings). Processes would access the settings using an API very
similar to the Dictionary access API, and would behind the scenes may
or may not talk to the central daemon (also started by authd).
So, so far we have the following:
Authd -- Graphical boot -- Command line for everything -- Log daemon
-- Central configuration management (akin to registry).
Now, for libraries:
libSystem vs libUser: libSystem is a library shared by every process
for providing basic system interfaces and data types. This includes
authd interfaces, logging, "registry" access, and system state/
configuration interrogation. libUser provides the ObjectManager API
as well as the ResourceManager, among other things most programs
need, but system daemons don't. Basically, if some piece of
fuctionality is not needed by the core daemons, it belongs in libUser
or higher.
Now, what do we want to provide to a user? My thoughts:
- The GUI should be customizable along the lines of KDE.
- The GUI should be scriptable, with a command prompt available at a
single keystroke
- The GUI should be consistent -- closing the window of one
application should behave the same as another, all standard keyboard
shortcuts should do the same thing for every application -- don't
make ^Q be Quit for the mail client, but 'Continue' for the terminal
application.
- Drag&drop should work at the GUI level, not the application level
(let the UI handle the big things, and notify the application that
something was put in that area).
- Python should be the standard scripting language, using Py/ObjC.
- CLI might be good to include as well, so other languages could be
used.
- The user interface library should use the Local/Network session
identifier to make decisions on how to display information to the
user. e.g. typing 'open mail' at an ssh prompt should bring up a web
interface or similar to the email, but typing 'open mail' at a local
command prompt should bring up the email client itself.
- Messages should be sent to the display server, such that commands
run remotely could interface with local programs (remotely launching
the IM program should still be able to use the local web browser,
unlike how Gaim with konqueror will do it all remotely on *NIX)
Underneath the user interface, we should provide the following
technologies:
ObjectManager -- A protocol-agnostic way of managing objects
(documents, photos, music, etc) on any medium, any filesystem, any
location.
- It is easy to write a manager for a new protocol.
- Objects should serialize automatically, and not use unmanaged
pointers.
- Object managers should use either the default encoder for encoding/
decoding objects, or use their own that can encode _any_ object. The
default (currently XDR) should be sufficient for 90% of encodings,
the rest would be handled with native encodings (store as mp3
directly, or jpg, etc, but that's done by the LocalFile manager).
AuthenticationServices (different name, obviously) -- Provide a way
to authenticate and run services under other users.
- Provide a way to launch a process as another user, using any
authentication method available.
- Provide a way to securely manage data (into KeychainServices and
SecurityServices)
- Keychain, Keychain, Keychain!
SecurityServices - Provide different security services
- Encryption
- Key management
- SSH keys, PGP keys, etc
- Signatures
- Certificates
Services and daemons: Talk to init
- Register services to launch at a certain event (boot, shutdown,
port connection, time, timeout, others).
- Deregister those services
- Manage bootup, shutdown, logs, etc.
I've likely got others, but this should be enough to start with.
More information about the gold-devel
mailing list