Terminals

[Albert Cahalan]

Look, there is no reason to care about hashes. What is the fear
here, that the jffs2 filesystem will fail? We have pathnames.

Permissions are granted by the user. The only exception is when
the OS is initially installed, or when the whole OS is upgraded.

Permissions are tied to an inode. Since the kernel enforces that
directories may not have hard links, one may also tie permissions
to a directory.

It'd be nice to have a way for activities to specify reasons to
grant various permissions. This isn't a requirement. It'd be nice
to to have a way for activities to specify permissions that are
of no use (and thus should not be offered in the UI). This is not
a requirement.

Signatures and hashes are complexity. Complexity tends to be the
enemy of security. The answer is really simple: every activity,
no matter where it comes from (claiming to be an upgrade or not),
gets sandboxed by default. Users grant permissions as desired.

Bitfrost sure is compatible with P_ROOT. Of course any such
permission would implicitly grant all others; such is life.
There certainly should be a way to specify that setuid is to
be respected, that su should be allowed, that UID should be 0,
that the user's real home directory should be used, or that
various capability bits should be enabled.

The more dangerous items might best be handled via commands
to be run at the Linux console, ensuring that nobody can hit
them with random mouse clicking.