I may be mistaken, but:
Android uses a global signalling system called "intents", where usually
each publicly accessible mode of an app has a corresponding intent. You
can launch an intent, which is (I think) globally visible, which tells
an app to turn on, or to activate the camera, or to re-scan the SD card.
Apps may also use Intents to signal things that they want a response to.
Apps may use intents to say "any other apps out there have anything
special they'd like to do with a github.com URL?", and other apps can
say "Yea, I'm the github app and I can open it" or "Yea, I'm Firefox and
I can open it".
What am.sh does (I think, haven't looked past the name) is mimic the
"am" command in Android, a terminal program that sends arbitrary Intents
as directed by the user. Am is usually only used as a debugging tool and
does not form the back-end of actual Android apps that use intents.
What the poster was suggesting, which I think is a good idea if security
can be ensured, is that Alien Dalvik should be written to expose Intents
on DBus so that applications outside Alien can see and perhaps respond
to what's happening inside Alien. I don't know much about DBus but I
imagine it's already written to accomodate DBus message sandboxing or
namespacing, so security wise I think the cards are likely to be in
Sailfish's hands, not Alien's. Though, as Alien is closed source and
likely doesn't run in a sandbox, it's not like security is really
something worth worrying about; too late! :)
On 22/02/15 21:12, E.S. Rosenberg wrote:
2015-02-15 21:23 GMT+02:00 Anton Thomasson <antonthomas...@gmail.com
<mailto:antonthomas...@gmail.com>>:
Hi
I recently managed to execute Android commands from outside of Alien
Dalvik.
This was achieved by looking at how it's done when apps are launched
and Alien Dalvik is started normally.
To see the resulting scripts, go here:
https://github.com/attah/alien-tools
Now to the point, I think these should be exposed for use in
sailfish native apps.
The way I see it being done is by adding a daemon that forwards
intents that it receives over dbus.
This solves a couple of things, firstly that it seems to require
root for the intents to take effect and secondly it enables us to
add a layer of security so that the user is prompted when app wants
to invoke an intent. This obviously needs a "allow permanently"
option, otherwise intents won't be very useful. Using a daemon also
takes care of the fact that it would have to execute in a rather
particular environment. That is what i have managed to set up in
alien-tools, but it is essentially the same as in
/opt/alien/system/script/start_alien.sh, which is what is invoked by
the aliendalvik.service. So spawning the daemon from there would work.
Polkit seems to be the way to do handle permissions, so that should
work out. I also think that this whole thing is better done, at
least in part, by Jolla. Especially since it needs to work with
Alien Dalvik which is 3rd-party, and so that it goes together well
with the workflow of the os in general. Thus this email. :)
I'm not sure how much else, apart from intents, that we'd like to
have exposed. I found that the "input" application works as well,
and many other should too. The scary part her is that i could send
input without being root. Not sure that is a very good idea. And
even if we would add som security layer, who is to check what is ok
and what is not? Intents at least have a limited scope whereas input
can do pretty much anything.
What do you guys think?
Regards,
Anton (attah)
_______________________________________________
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to
devel-unsubscr...@lists.sailfishos.org
<mailto:devel-unsubscr...@lists.sailfishos.org>
Hi attah,
I'm not familiar with android so forgive me if I'm completely
misunderstanding what is happening here.
I mainly have lots of questions and probably not so much extra input...
Are you basically using alien as a 'shell' (just like one would use
tcsh, zsh etc) to execute jars? Isn't that how alien always works?
What are these intents?
My gut says that more access might be dangerous, also in the sense that
someone may end up writing a jolla native app that still depends on
alien being there and having a ton of unnecessary overhead (without even
talking about the security implications), surely not the aim of jolla or
the community if we want to improve the jolla ecosystem...
(What are the security implications of what you are proposing?)
Hope you don't mind my flood of questions, the subject matter looks
interesting to me and so far no one seems to have commented at all...
Regards,
Eli
_______________________________________________
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
--
Scientific Director, IndieBio Irish Programme
Got a biology-inspired business idea that $50,000 -
& 3 months in a well equipped lab could accelerate?
Apply for the Summer programme in Ireland:
http://indie.bio/apply-to-ireland
Twitter: @onetruecathal
Phone: +353876363185
miniLock: JjmYYngs7akLZUjkvFkuYdsZ3PyPHSZRBKNm6qTYKZfAM
peerio.com: cathalgarvey
_______________________________________________
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
