[Tizen Application-dev] Executing shell command

Carsten Haitzler (The Rasterman) tizen at rasterman.com
Sat Mar 31 03:41:47 GMT 2012

On Fri, 30 Mar 2012 18:29:02 +0000 "Schaufler, Casey"
<casey.schaufler at intel.com> said:

> > > so you do care about "citizenship status".
> No, I don't care about emotionally loaded terms in a technical discussion.

i don't much care for people trying to avoid the topic by trying to change what
is a perfectly good summary/description, as this is precisely wat the situation
is, according to you. web apps are by design and intention never going to be
able to be as complete and useful as software that is native. thus they are 2nd
class. less powerful/capable. that is fact.

> > > you believe "apps" (web
> > > apps that have been downloaded and installed - a very 1970's concept
> > > there) should, in general, all be 2nd class citizens and never be
> > able
> > > to replicate the functionality of the core system.
> When you accepted the web app abstraction you had to agree to live
> within that abstraction. A shell environment provides facilities that
> are not constrained by adherence to the abstraction. As such it might
> be used to bypass the higher level implementation of the abstraction.

i never agreed to live within a web abstraction. i have no like for web
development, but its the only thing that tizen supports for 3rd party
development, so naturally developers will be most unhappy when they start
hitting roadblocks. i don't believe in neutering of developer freedom in this
way. neither do most open source developers i know.

> > > i.e. be a launcher,
> > > or task manager, or any one of many things that require access to
> > > things like /proc, or kill() or fork
> > > +exec() etc. :)
> Yes! You've got it! You're in an abstracted environment. Y'all asked
> for an abstracted environment. We're providing an abstracted environment.
> That means you don't get to do things that are inconsistent with the
> abstraction. 

and as no alternative environment is supported, then this is the ONLY thing
people can do - and that is WHY people ask these questions.

> > I tend to agree with Carsten here. An installed local web app should
> > behave no different than a native app.
> > It would be sandboxed as a normal native app.
> > So I don't see any security issues here, no more than what a native app
> > would bring.
> Even native apps are constrained to the abstraction of the environment.
> That is what makes native application support difficult. Providing the
> APIs for native apps is easy. Protecting the abstraction from the native
> apps is what's hard.

not hard at all, i you abstracted in the right way. ie put elements you want to
protect behind another uid and remote service (dbus/sockts etc.)

> > Could this be further explained? I mean what new security issues could
> > this bring into Tizen.
> It's nothing new. It's just the basic old notion of circumventing
> part of the system security facilities.
> > Note: we're not talking of web apps executed during a normal browsing
> > session.
> > We're talking about installed native web apps. If that concept is even
> > being considered.
> The security issues are pretty basic. The operating system kernel (Linux)
> enforces its version of security. The WRT enforces its brand as well. The
> WRT uses and takes advantage of the kernel security features, but in the
> end does a significant amount on its own. This is how is must be to support
> things like one-time access and controls based on such complex conceptual
> entities as "telephony". If you drop down below the abstraction in a shell
> you lose the ability to provide one-time access and the context to control
> telephony. Once we move all of that abstraction into the kernel (not
> happening any time soon) we will be able to allow shells on top of web apps.
> Until then, the price of the abstraction will include restrictions on the
> generality of the facilities available to the developer and the user.

i'd say wrong. if your telephony lives on the other side of a service (which
it should) you can make it one-time via that service (if it lives on another
uid). i assume here one-time means you get to do 1 "transaction" (e.g. initiate
1 call). after that you re denied until re-authorized for that connection. a
connection gains initial authorization via system means (telephony subsystem
pops up a dialog requesting the user to are to allow the app to make its call,
being god, for 1 transaction). if can implement many & varied versions of this
to (authorized for limited time, forever (have to provide some kind of auth
cookie/id), for the rest of your session etc.)

perfectly possible.

Carsten Haitzler (The Rasterman) <tizen at rasterman.com>

More information about the Application-dev mailing list