[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