moko running everything as root

Kevin Dean kevin at
Sat Jun 14 06:23:41 CEST 2008

On Fri, Jun 13, 2008 at 10:10 PM, Joerg Reisenweber <joerg at> wrote:

> My opinion is averse. There's no valid reason to abandon the very simple
> concept of users, groups, and permissions, just to have an "easy start" on
> development (fixing apps later on is a PITA). If you don't care from
> beginning, you'll end up where Vista is right now.
> Where is the problem to chmod any file in /dev, /sys, etc. to do rdate, power
> off, opkg etc (ok, for opkg I myself would prefer to be asked for root pw).

The difference, as I see it, is we can be sure that a user has the
capacity to physically disable the device. Having user seperations
makes sense when you have some restricted users and some "root" users.
Anybody who has dealt with security in a mission critical situation
will tell you that having those kind of permissions systems when the
INTRUDER has physical access to the device is next to pointless.

> Or make apps SUID! Do we really have to repeat this annoyance yet *another*
> time?

What benefit does havign things like OPKG SUID give us that having
opkg run as root doesn't? The reason for seperation of privaledges is
to prevent an unauthorized person from ruining the system (a
seceretary deleting anything ending in .conf because she doesn't use
those files on a network server...) by an unprivaledged user.

If you look at studies on why "Linux" isn't hit by viruses you'll see
the root/user seperation featured as #1. #2 reason is "diversity" - A
virus undetected on  Red Hat might not be invisible on Debian and the
work needed to ensure that was the case is about equal to ensuring
that every device driver ever written for Windows was bug free (i.e
next to impossible)

> If the user *really* wants to run these apps in the way you assumed (being
> pissed off to relogin as root), why not use ageold mechanisms like sudoers,
> wheel etc?

User "John" running sudo rm -rf /* is better than root running "rm -rf
/*" because...? If you want security, unprivaledges users must NOT
EVER be able to run privaledged commands. In a corporate environment,
it is safe to assume that all of the people using the filesystem will
have various roles. This assumption doesn't exactly hold when the
entire filesystem is small enough to be put in one's pocket.

> To me it seems this is an *extreme* inattentiveness of developers, even worse
> a ridiculous one.

As I see it, it's being realistic when using technology designed with
restrictions to suit a multi-user environment in a situation where
only a single user. In a networked and shared environment, the
deletion of a single user's browser preferences isn't too important as
long as the integrity of the majority of the network exists. In a pure
single user situation, the integrity of the user's data IS network

Feel free to ask an iPhone user what would be worse, the entire
dataset of their device being erased, or only their phone numbers,
pictures, music, settings and so on. in both cases, that user would
NEVER use another device from that company. When "the user" is more
important than "integrity" there is NO way that traditional UNIX file
system permissions add a layer of security.

More information about the community mailing list