[Tizen Application-dev] Executing shell command

Ryan Ware ware at linux.intel.com
Sat Mar 31 23:50:21 GMT 2012


On 03/30/2012 08:41 PM, Carsten Haitzler (The Rasterman) wrote:
> 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.
That is true simply by the fact that they are running in a WRT.  It 
doesn't matter what you do with the WRT, the environment will never be 
the same as a native application and is never intended to be.  
Otherwise, they wouldn't be writing in Javascript.

>>>> 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.
What you like or dislike in this area is irrelevant.  It is the stated 
direction of Tizen and while you disagree with it, many Javascript 
developers don't.

>>>> 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.)
If you abstracted in the right way?  The abstraction is already given to 
us.  It's called HTML5.  That's what we live with.  If we could go ahead 
and start with a brand new abstraction, we might be able to do that but 
it's not the environment we live in.

>>> 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.
>
I think this shows a lack of appreciation for the security issues 
involved in Web Apps.

The bottom line is that allowing shell access for web apps would 
invalidate many of our security requirements.  If we want to revoke all 
of those security requirements, I don't have a problem with that and it 
will make my life much easier.  However, since those requirements do 
exist and I'm responsible to ensure we don't violate those requirements, 
we won't be implementing shell access for web apps.

Ryan


More information about the Application-dev mailing list