Shared publicly  - 
 
android.permission.ACCESS_SUPERUSER

Android has a way for apps to create and request various permissions via the AndroidManifest.xml file. This is how the list of permissions and features shown in an app's Google Play description is generated. Superuser should definitely be listed there. But currently, no such permission exists to be enforced, which is a terrible precedent:
You can download an app, and without your prior knowledge it can request Superuser access.

After talking with +Ricardo Cerqueira about this, we've decided on a strategy to ramp up and start enforcing this good practice.

0) Add a new permission with the Superuser, "android.permission.ACCESS_SUPERUSER".
1) The new Superuser will simply warn that the developer is not declaring "android.permission.ACCESS_SUPERUSER" in the manifest. (as seen below)
2) Add an option to Superuser to automatically deny Superuser access to apps that do not have this declared.
3) After 6 months, this option is enabled by default.
4) After 1 year, this is no longer optional (always on).

This is an insanely trivial change for an app to make, and will assist with the transparency of root apps on the market. So there's really no excuse for the developer not to do it!
555
63
Aleksandr Ivanov's profile photokarawi GamalEddine's profile photoKevin Carter's profile photoKevin Yuan's profile photo
164 comments
 
I like the direction in which you're taking this, Koush.
This should be a permission with the "dangerous" protection level.
 
Great! Hopefully the other superuser app developers join your initiative.
 
So your goal is for this permission to become the norm for root permission apps, and eventually Google should add that permission to it's list of displayed permissions in the play store?
 
+Alexei Watson Google doesn't need to add it. It's automatically sourced if you have a supporting Superuser installed.
 
Yeah sure I get that, in theory though, they could use it in the play store listing to show a user before install, that the app will request superuser. Anyway, I think what you've done is a really good idea for security on rooted phones.
Paul W
+
2
3
2
 
It's not a big change I suppose. Though there should be greater input from the community. Though to be fair, I'm yet to find an app that's requested SU which I didn't know would. 
 
+Alexei Watson There is no Play Store list of permissions. It takes the permissions from the manifest and if it is a self declared permission the description and name is taken from the app.
 
supersuser is here since the begining. how come this issue has not been at least debated before?
Chainfire
+
1
2
3
2
 
I had some initial concern due to the docs stating the permission name must be unique and the user installing multiple su apps (to switch from one to the user) if both have the permission defined. In my (non-extensive!) testing it does not appear so far to be an issue as long as protectionLevel is normal or dangerous ... so that's good.
 
Now apps can get your permission to ask your permission for root!

More seriously, though, is it the eventual goal to not show the Superuser prompt for apps with this permission?
 
Not to be "that user," but can the permission name be ".ACCESS_SWITCHUSER" or ".ACCESS_ROOT"? I know the community has run with the whole superuser thing, but that's not actually what su stands for, and having the permission be .ACCESS_SUPERUSER does make it seem more tailored to a particular app rather than the binary which the permission should be related to.

The idea, though, is a great one. Thank you for all you do Koush!

All the best,

-Sam
 
Well, it's either something like that (good idea, btw) or some one comes up with an app that works something like Little Snitch, but for permissions. 
 
+Chris Hodapp I don't think that the prompt for getting permission will vanish. But apps that don't have the "android.permission.ACCESS_SUPERUSER" permission set in the AndroidManifest.xml simply won't be able to get su permissions at all (no matter which implentation you are using).
Translate
 
How many times I gotta pay for damn touch recovery? 
 
+David Smith You can flash it for free from his site or flash a flashable zip through your current custom recovery
 
+Sam Stuewe woth the new ACL model and Selinux, don't see how any app would ever run as root (id 0)
 
+Koushik Dutta there's one situation when the permission model doesn't work. Permissions are only granted at install time. So if for some reason the app asking for Superuser has been installed before Superuser (be it only an app that works without root like Solid Explorer) then the permission will not be granted. Had learned that the hard way in one of my apps.
 
+Fernando Miguel, I'm confused how that's relevant. I'm just proposing a less front-end biased naming scheme.
 
Ideally, that should be in core AOSPA. Well, I can dream :P
 
While you're at it... It would be cool to try to have a standard 'feature' (to be used in <uses-feature>).  This way apps that need root can be filtered by the Play Store.  Hope you know what I'm talking about :)
 
+Koushik Dutta why not use another package? like, for example androidx.permission or com.superuser.permission? Google controls android.permission package. If they add that permission in the future with a different semantic, it will be a nightmare for developers.
 
if android.permission.ACCESS_SUPERUSER is already used in the market - then its the correct value to look for.
 
Should it really be this "wide"? Why can't there be many permissions: ACCESS_IPTABLES (DroidWall), CHANGE_SYSTEM_PROXY (TOR), ACCESS_THIS_PARTICULAR_SYSTEM_SETTING, etc?
Why shouldn't the user be able to control this with precision?
 
+Alex Riesen That would most likely require the extension of the SDK. The best way for that kind of functionality to be present is to submit patches to AOSP.

I like this way of it. If someone @ google could make this a filter on the Play store, it'd be cool. (for example, downloading an app that requires root on a device isn't rooted could say "This app is incompatible because you are not rooted" -- would stop tons of bad reviews)
 
I was not aware that an app could define permissions not ddfined in AOSP and have them show up in the permissions dialog on install 
 
+Scott Miller Yup, for example to protect content provides (like gmail etc do) you need to define your own permissions
 
+Sam Stuewe Because the username root has been traditionally classed as a "superuser."

+Koushik Dutta A different name could be used, like ACCESS_AS_ROOT or ROOT_USER or ADMINISTRATOR.
 
+Neal Gompa, superuser is a petname for the 'su' binary due to a misunderstanding of what su stood for. Root refers to the colloquial name for UID 0 and Switch User is the actual meaning of "su." Superuser, officially speaking, is just the name of the App, hence why I'm not a fan of its being the name. I'd still advocate for ACCESS_SWITCHUSER
 
+Gabriel Ittner +Joe Simpson yes, it would. But it is your , the developers, problem to solve. Making decision to give full access with one simple option will certainly not increase the security of the system. "Why would this particular app need full access when the only thing it does is displaying iptables statistics?!"
 
ACCESS_SU should make everyone happy? :)
 
+Danny Baumann it doesn't matter. Staying with the example Solid Explorer, you could already use it without root. Later you decide you want to root, install Superuser, but Solid Explorer will not be granted the permission. Android only checks the permission when the app is installed. During install time there was no Superuser, hence Android can't grant it. So the only option to make Solid Explorer work with root is a reinstallation, and that's a NO-GO! It's also possible there might be issues when switching between different Superuser tools. I really hope the Superuser permission will not be introduced! There's no big security benefit but instead 1 stars for apps that seem like they don't work with root. Otherwise it would be a nice and more cleaner approach to su'ing, but unless there's a more dynamic permission management in Android I rather consider it a bad idea....
 
hello iam mina samir in germany we can be frinds
 
+Alex Riesen Ideally there would be finer grained permissions to do this stuff without root (which is what CM does). But obviously that is not possible unless you are on a custom ROM.

CM policy is to not to use root for anything, and properly use and extend the permission model.
 
Or "Switch user," I'm pretty sure that's what the original Unix command means.
 
Hey can any one tell me how to root Micromax A52 its a Android 2.3.6 device.
 
+Sam Stuewe I don't mind changing the developer visible permission name to ACCESS_SU.

I'd rather the naming remain Superuser though, in the human readable description, as that is the user friendly and recognized name. I prefer that to "root".

Semantically, I agree that Switch User is correct, but there is an opportunity for confusion there: a user may interpret that to be switching users in the multiuser environment (introduced in Android 4.2).

Conveying the right message is important, even though it may be a misnomer:

https://plus.google.com/u/0/103583939320326217147/posts/1bdHYBa7yb8

I also disagree that Superuser is the name of "the app", as that term has predated Android :P
 
Is this available for users yet? I'd love to try it out
 
Zed Jensen I have tried a net trick to root but nothing happened so I need some expert help.
 
+Koushik Dutta, whether or not the term predated Android, that is the name of the app. And, it's true that conveying the right message is important, the problem is that, as I mentioned before, it seems to focus the permission on the app itself, not on the binary, which means if another SU manager implementation (SuperSU, for instance) wants to implement this schema, it still appears to reference this app. I think ACCESS_SUBSTITUTEUSER or SWITCHUSER would be best (especially since you should be able to add a description of what the permission is and have it display on the install prompt), but SU would probably be more widely understood. As you are the dev, it is (of course) your call, but I stand by the notion that perhaps it would be best to have the permission focused on the binary and not on the app.
 
+Sam Stuewe FWIW, I (and CM eventually) are reusing the Superuser name for the app reboot. I think "debranding" it will help with that issue.
 
In that case, +Kuntal Mondal , post a link to whichever post you tried and why it didn't work and I'll see if I can help you out.
 
I don't care what you call it, but root should be a declared permission.
 
+Ronald Ammann Currently, I am checking to see if the permission was declared vs granted. It won't break anything.

I'll keep your scenario in mind; as that is a valid edge case.
 
+Joe Simpson I definitely have to agree with you in case of taking input from the user base. But why in the hell should we allow them to know if we are rooted or not? It should be shown at the time of installation. FYI there's always a root user even if there is no su binary. So you are always kind of rooted.
 
You have to say YES RUN, the app does not just have super user access.
 
+Ronald Ammann Ah, now I understand. I was thinking from a CyanogenMod perspective (Superuser in /system = always present), but completely forgot about installing it on a stock ROM.
 
+Koushik Dutta I have to say, while I think this is a splendid idea on the whole, I sortof feel like milestone 4 is unnecessary and, ultimately, undesirable. It (potentially) unnecessarily breaks older apps that may not be supported any more but still work and, furthermore, unnecessarily and artificially limits user choice in the matter. If I want to allow an app that doesn't declare root access as a requested permission to destroy my phone I should be allowed to do so. Sure, make it obnoxious to turn on by all means, but completely removing the mechanism (and thus limiting user choice) seems counter to the rationale of most of the entire point of rooting to begin with.

Just a thought.
 
+Koushik Dutta  Yea, I have to say that I I have some root applications whose source code was lost due to a hard drive crash, some years ago, and thus cannot be updated. I'm sure that my apps are not the only ones that would be affected negatively because of this. While I think it is a good idea, I think I agree with the comment above, you will effectively break many applications that are not updated anymore or cannot be updated. 

I also then have to question what right you have to decide when all of these applications will no longer work because you feel, after almost 5 years of Android, that every root application should now declare this permission.....

I think it is a great idea, but I think it is a bit too late to "Strictly" enforce this idea. 

That being said, I'll gladly update the applications I can with this new permission.
 
+Kevin Carter , +Stephen Erickson Sorry, but I really can't agree. The thought of an abandoned app with root-level access to the system worries me, and 6 months of users being creeped out by "SORRY, CAN'T USE THIS THING!" messages by default should provide ample notice :-D

That being said... We could just replace the complete cut-off with a series of  extremely uncomfortable hoops. "(Are you sure? Really? Type "yes, I understand this is a bad idea". OK, you have 5 seconds to use this)" :-P
 
+Ricardo Cerqueira You are making a decision that will affect app developers everywhere and users everywhere, how can you make a decision like that? I agree with the implementation, but the cutoff is a bit extreme imo.

It's especially extreme when root applications have been developed for almost 5 years, there are probably a lot of applications that people still use that are not updated anymore.

Furthermore this implementation serves as a nice notice, and that's it, it doesn't address any real security concerns since the user has to grant superuser permission to the application anyways. 
 
+Stephen Erickson True. And the decision hasn't been made, a lot of things happen in a year, especially in this business. :-)

The point isn't as much enforcing actual security, but more making users realize what they are getting into. Android isn't different from the rest of the computer world, and a lot of consumers just click anything that looks like an "OK" button. From experience, even with CM, it's pointless to raise alarms when the app developers start their app's description by stating "You'll get such and such error. Ignore it, that's normal!".

Ever tried BatteryStats? It's a pretty nice app for measuring power consumption, and does a bunch of stuff in a background service. Every now and again, it pops up a SU request with no matching foreground activity, and a far from obvious message as to what it's going to do or even what app it belongs to; That's how I found out that app existed, when a friend was showing off a new phone, that popup appeared, and he quickly pushed the "OK" button without even reading it (no way he had the time). Maybe a cut-off is too aggressive, but a simple warning or confirmation dialog won't cut it either.
 
+Ricardo Cerqueira I would be fine with something in the middle, and let me be clear, I like the idea. 

I just think the hard cut off is a bit too much, jumping through some warnings, I could agree with that as you mentioned in two comments up.
 
So implement a difficult to find override option?
 
I don't know if it's so much a difficult to find override options or something like what Ricardo suggested above, making the user type YES or something to the degree that they cannot just hit a button to proceed
 
+Ricardo Cerqueira Don't get me wrong. I really like the idea. I guess my overarching point is that a great many of the people I know got into rooting because they wanted to do things the carriers or handset makers thought they aught not to be doing with their phones. The decision was made for them. In implementing a hard cutoff you're acting in a similar fashion; you're making a decision for me. All it's really likely to do is to get me to go use something else to accomplish the same task as un-overridable, hard cutoffs like this just feel a touch heavy-handed. Make it obnoxious to work around, sure. I can get behind that. Just give me the ability to make decisions for myself. I'm a big boy. I don't need my hand held for me. It's a large part of why I root to begin with.
 
+Stephen Erickson +Ricardo Cerqueira I'm fine w/ it remaining available, with serious hoops, after a year. A year is a long time, and the hard date is just an idea.

Though I'm a bit sketched out by any app that doesn't update itself after a year.

But man, I feel like we're all holding up the boat because you didn't check in source to Github ;)
 
+Koushik Dutta Yeah... I mean... ostensibly I agree with the sentiment, but I get a bit sketched out when devs remove features entirely "because of reasons." 

Like I said, feels a bit heavy-handed all things considered. A bit like the OtherOS fiasco.

I suspect that I, and others with similar opinions, might be more amenable to the idea if there were a rationale to go along with the decision.
 
+Koushik Dutta yea, I failed hard early on... Live and learn... However I also feel the same way as +Kevin Carter  stated above.

I'm also sure I'm not the only one who didn't properly backup source code, and some devs also lose their signing keys (This is something that could be fixed but I know some apps wont be re-released under a different package name...)
 
This sounds superbly sensible to me, I had no clue prior to now that an app could easily become a superuser by stealth.
 
+Gary Dillon How do you mean an app can become superuser by "stealth"? A user still has to grant superuser access to the application. (assuming that the application is not exploiting some vulnerability to become root which this wouldn't do anything for anyways)
 
+Koushik Dutta Looking at stock permissions, I'd go with either SUPERUSER or SUPER_USER. the convention for permission names appears to be "extremely verbose" ("android.permission.ACCESS_LOCATION_EXTRA_COMMANDS", for example. At a glance, I don't see acronyms)
 
+Stephen Erickson I got the impression that was what "You can download an app, and without your prior knowledge it can request Superuser access." meant?

If not, it's not such a biggie then.
 
+Gary Dillon Ah, yea it can "Request" access, but that access has to be given by the user. Koush wants to notify users that the app will "Request" this access before the user downloads it. What he is suggesting is the correct way that we should be notifying users that an app needs root access, versus just putting a notice in the description that it requests/requires root access...and some devs don't even put that notice in.
 
On the other hand, we have the possibility to disable the cut-off in development settings.
 
+Anders Tyft Which is a perfectly sensible alternative in my admittedly humble opinion.
 
+Koushik Dutta You could do the complete cutoff only for apps with a certain minimum build target. Similar to the sd card read permission which is currently only enforced when you enable it in the dev settings, but will be enforced in a future Android release.
 
I've been a fan of your work since the Moto Droid 1! Your contributions and projects posted on ModmyMobile, XDA & Droid Forums over the years have motivated me to study Linux systems. Also, I've been using apps like Ninja/Metamorph, Rom Toolbox, Root Explorer, Linda Manager, Root Browser, Busybox Pro, And Titanium Backup to modify, backup & create my own personal program tweaks on all of my Android devices. You are like a GOD my friend! Keep up the GREAT Work:-)
 
+Koushik Dutta  We need to be careful with a "requires" permission here. Some apps won't be useful at all without root access, and may wish to indicate this fact to users by requiring a permission. But other apps can still be useful if root access is denied.
We need to be careful not to scare users who don't have a rooted phone. Just because they saw the word "root" or "superuser" somewhere at or before install time they may decide not to install and try your app. "Oh, it requires root, that's not for me..."
 
+Stephen Erickson actually, no. The suggestions were different and too many people have been leaning toward Superuser and access Su.

The permission requested is to switch user. That's literally what the su binary does. No need to request access switch user. You're requesting to switch user. 
 
+Adam Outler I had to reread those last two sentences a couple times, but, yeah, that is more accurate.  But, it may not be helpful to the normal user who has no idea what the permission is for.
 
This was discussed...

Koush stated:

"I'd rather the naming remain Superuser though, in the human readable description, as that is the user friendly and recognized name. I prefer that to "root".

Semantically, I agree that Switch User is correct, but there is an opportunity for confusion there: a user may interpret that to be switching users in the multiuser environment (introduced in Android 4.2).

Conveying the right message is important, even though it may be a misnomer:"

Now, this is in response to requests for the permission that will be seen by users, the permission that will be used and seen by developers implementing this is still up for debate I believe.

If you were meaning the latter rather than the former than I apologize you are correct. 
 
Superuser means nothing outside of the Superuser app. I think that would be promoting ignorance. I find "access superuser" to sound nothing short of stupid.
 
+Adam Outler What Root user doesn't know what SuperUser is? You are arguing for a technical term to be used to explain something to many that may not even know what it means? "Access Superuser" is absolutely the best option to display to the user, not many know what "Switch User" is or what it refers to.
 
+Adam Outler The term Superuser predates android and the superuser app. In fact, su was originally abbreviation for SuperUser, as that the first su binary only did root escalation, and did not in fact Switch Users:

http://pthree.org/2009/12/31/the-meaning-of-su/

The term "switch user" will most certainly confuse users and should not be in any user facing description.
 
Hm, so the question is: Do we dumb down our terminology to the point of error to help the ignorant masses in the short-term, or do we use the correct terminology and risk a myriad of ignorant users being totally confused and messing things up out of their confusion? I dunno.
 
I think I'm going to agree with Koush and Stephen.
 
+Koushik Dutta

SUPERUSER, SWITCH_USER or SU - it's all fine to me, that debate is not interesting for the end result, and we all know what it stands for.

Neither do I have a problem with switching access off to those programs that do not request this permission in a year or so (though the user will probably get an override switch in settings). 

Though +Stephen Erickson does present interesting cases of the signing keys or source being lost, a year is a long time, with ample time to prepare. Most apps not updated for a year are likely abandoned, and it would not surprise me either if those root apps would not be fully compatible with whatever Android version we will be running at that time. For those few cases where there's really nothing that can be done there's the override switch.

What worries me a lot more, and will ultimately decide whether or not to fully enable the restriction by default are the potential problems like those +Ronald Ammann has put forward that may be structural. If no workaround can be found, those may be showstopper issues.

( though I do oppose the usage of android.permission. prefix for the other signatureOrSystem permissions you have defined )
 
Actually, at this point, since it seems that the permissions are so verbose, I'd say something like ACCESS_ROOT_PRIVILEGES might actually be best. But, again, it's Koush's call.
 
+Chainfire just because an application is abandoned by the dev does not mean that users are not using it anymore. You could potentially make so a user is unable to use an application that he/she enjoy using on a regular basis.
 
+Chainfire ah, right...well I am fine with that. (sorry)

That still eliminated milestone 4, eliminating said override.
 
+Chainfire The other permissions you mention are implementation specific and not necessary with legacy Superuser or SuperSU:

    <permission
        android:name="android.permission.REQUEST_SUPERUSER"
        android:protectionLevel="signatureOrSystem" />
    <permission
        android:name="android.permission.REPORT_SUPERUSER"
        android:protectionLevel="signatureOrSystem" />

They are just to prevent the activities from being launched by anything but system/root.
 
+Stephen Erickson ,chainfire said something about using a override switch in his last sentance.

+Chainfire has a good point. Why would a linux level function need an android.permission? linux.permission.SUPERUSER or system. Su does nor have to do with android.permissions.

It might be best to warn users that an app does not have the required permissions for the next 6 months until it has sunk in and developers have had time to clear the warning. Otherwise a full-on deployment would kill every app on the market.
 
+Koushik Dutta yes, I know, that was the point -  shouldn't they be called "com.koushikdutta.superuser.permission.REQUEST_SUPERUSER" (etc) because of this ?

+Stephen Erickson I do not believe in eliminating such an override at least at first. Once the option to block requests from apps that do not have this permission listed becomes enabled by default, I think we'll notice quickly whether or not this is even a problem, or we're just all wasting our breath on it here.

+Adam Outler That sounds suspiciously like what Koush proposes in his post ...
 
I'm tempted to suggest that "uses-feature" is more appropriate, as it allows you to indicate whether the feature is required or optional. But I'm not certain what impact this would have on publishing to the play store.
 
+Chainfire yes, that is what it was, prior to an aggressive sed inplace operation.

I'll be fixing it.
 
+Koushik Dutta do you feel this would be helpful in the fight against virus scanner vendors? Is this the idea? It may just provide an easy target for them. 
 
I really don't see the point of this. Users would only need this protection or notification from malicious apps, sorry to reiterate what +Stephen Erickson said but a developer with malicious intent can circumvent your scheme. Be sure that they will do just that.

I'm not certain this isn't just one more claim to fame for your resume. Worse than that, I feel like this is a ploy...like a paid app is coming.

I paid for SuperSU so I could have a running log of what commands were being ran by known root applications, if developers are looking out for end users best interest...shouldn't this functionality be free.

No offense intended +Chainfire as I don't mind supporting your work.
 
Oh and if +Koushik Dutta is truly trying to improve security and no paid application is at the root of this then I apologize in advance.
 
I really hope that this permission will make it to Play Market some time to warn users.
 
+Aleksandr Ivanov If the app that created the permission is installed, they will see it listed in the Google Play permission list for apps that require it. If it's not installed, the permission will not be listed.

In other words, yes it will make it.
 
What are you guys going to do about circumvention?

I can provide an example of an app in the market that can bypass superuser/supersu, it's open source so I would rather not just list it here for a couple of reasons.
 
+T Turner Post about it in a status you share only with me and Koush then, instead of public ...
 
I keep thinking about this..  actually obsessing about it...  This tiny permission addition may upset many things in the Android ecosystem, and I'm not just talking about app developers. Please keep in mind that I respect both of you greatly, +Chainfire and +Koushik Dutta .  Understand that I support your decisions either way but I want to bring some possible outcomes to your attention to be addressed. 

1. "Malware Scanners" may flag any app which uses the permission as malicious.
2. OEMs may actively block any apps which utilize the permission from their frameworks.
3. Google's stance is that root should never be needed, so its entirely possible that a point may come where all root apps are removed
4. Users may be encouraged to use an alternate non-permissions-declared Superuser variant once it is enforced because it is easier.. or maybe even a blind-escillation su such as found on the JynxBox.

I understand that this feature/permission is in-line and makes sense from an application and security standpoint. The point I'm trying to make is that until now, root access has "flown under the radar" so to speak. Motorola would probly be the first to say, "thats the thing responsible for all the problems", and deny access from stock ROMs.  This new permission would stick out like a sore thumb and give security "experts" an easy target.

If you guys decide to or not, I will respect the decision.  I will even do an episode of XDATV featuring the new permission requirement so as to help familiarize people with its use.
 
I think the benefits of requiring the permission outweigh the detriments.

Malware scanners:  Plenty of other ways malware scanners would flag such apps.
OEM abuse:  Highly unlikely, since anyone that wants to block su access this badly is already going to be compromised as a result of the whole process of adding a setuid su binary to /system...  By the time this permission matters, it's already "game over" from an OEM perspective.  If this ever becomes a problem, the community can route around such braindamage then.
Google's stance:  That's their official stance, but people keep finding reasons for root access Google never envisioned.  Yes, Google often takes some of those features and makes them "non root required" ones (like adb backup), but I don't think they'd ever go so far as nuking all root apps in sight.
Users installing crippled su variants:  I don't think this will happen...  Not if ALL of the trusted sources of su binaries (and associated escalation control applications) are doing it.
 
As far as naming the permission itself, how about:
EAT_BABIES
CLUB_BABY_SEALS
 
From a technical perspective, I like the idea.  From a practical perspective, I'm terrified of it.

I would offer that the current method of per-app verification is vastly superior.  More often than not, users are not going to look at these permissions.  Having a dialog appear that forces you to confirm root access per-application is far more secure.

Products which provide optional additional root features will be severely hurt by this.  As the author of FX File Explorer, my first thought is that the majority of my users who "just wanted a normal file manager" are going to be very ticked off when they see this permission appear after an update.  If you don't have root, I imagine there's a nonzero chance that you're terrified of the idea of having root.

PS (if you do go ahead with it):  I'd be a bit concerned about using anything starting with "android.permission."  I'd infer that it's illegal per the API for third parties to introduce new permissions with this prefix, unless there is specific documentation to suggest otherwise.  I'm not advocating a reverse-domain-name style package name, but something like "androidsu.permission." or "androidroot.permission." might be a better prefix.
 
+Tod Liebeck per app verification is not going anywhere.

This is to give visibility on Play for apps that do use root.

Furthermore, the permission does not show up if the user is not rooted (ie, does not have superuser installed).

Carbon, for example, has both root and nonroot functionality. This permission is completely invisible if the user is not rooted.

Basically, it provides more up front visibility to root users that an app uses root at install time.

The user can configure it to automatically whitelist apps that declare the permission get root, but that is certainly not the default behavior.
 
Since this permission is defined by 3rd party app, what if some naughty app also defines it, but with a "joking" description? This will mislead users if they installed it before SuperUser.
 
+Oasis Feng can't do anything about that. superuser is one of the first things installed though, as the rooting process generally wipes the phone.

also, i think /system apps take precedence over /data apps in terms of defined perms.
 
Well, you can't say rooting generally wipes a phone. Samsung is the most popular brand and rooting does not require wipe. 
 
Hi Koush, I feel the permission naming should be branding neutral. Since rooted apps call the su binary, why not call it it ACCESS_SU or  ACCESS_ROOT EXEC_SU EXECAS_SU EXEC_ROOT EXECAS_ROOT or RUNAS_{SU/ROOT} . So maybe different namings can be allowed now and see which one stick and later enforce that. Also I would like see finegrained permissions like MOUNT_SYS_RW COPY_TO_XBIN COPY_TO_BIN or SU_XRW_BIN Or even apps could be restricted to run only SU_X_{progname} . We may need to create a registry for root apps to register their requirements and for superuser apps to take care of that. So idea is that if a root app requests a finegrained access such as SU_X_LS and ACCESS_R_XBIN , that program could only do su -c 'ls /system/xbin'   and a permission such as ACCESS_FULLROOT would allow anything... Also we need to create a open online registry of trusted apps and non trusted apps that all superuser apps can access so that they can block/warn about apps that do su -c 'rm /system/bin/*' . what do you think? Note I am a android noob - more into linux. 
 
As far as I'm concerned, step #4 is going to be a pain in the ass for me. I'm using 1-2 legacy apps that were last updated in 2010 and are probably not likely to see future updates to request this new permission. If Superuser is really going to forcibly reject su requests to those apps, then I'm going to need a replacement for Superuser...
 
What about non-consumer applications? Some use android for academic, technical and industrial applications which require root in most cases. Would you force those users to chase developers every time you change permission policy? Perhaps you should make exception for apps installed from Unknown Sources.
 
Has there been any feedback from the Android Developers or Play Store folks about this yet?  I still have a (possibly crazy) fear that a carrier would delist all apps with this permission (under the guise of security or user agreement).  Yes they could have done it before, but it would have been hard.  This gives them the ability to do it with a SELECT statement.  I imagine that six-month deadline is approaching, still deciding whether or not to add this to FX.  Any support/acknowledgement/acceptance of this permission from OUTSIDE of the root development community would make that decision much easier.  And does the six-month deadline have a specific date?
 
I think adding the permission check is beneficial. Even having an option to deny apps that don't have it on the USER end. I also think being arrogant enough to set requirements and deadlines for when developers have to integrate the permission before it is no longer optional is counterproductive. Until you can convince carriers that root is something welcome on their devices, or convince Google that carriers have no say in Google Play content, it is not really up to "3rd party" developers to attempt to rewrite the requirements for applications that are submitted to such platforms. As for the users, I hope you are certain of them being avid readers of every notice and changelog, Because this is not official Android documentation and not every developer follows your work, but some of their users may. Now those developers are left diagnosing issues that, unless every user suddenly became proficient in logcat and explaining crashes with more than "It FCs", will seem like unexplained random occurences. I think the most important thing to remember here is while your application is widely recognized, it is still only one option and hardly far enough ahead of any others to warrant making rules.
 
+Steve smith you will never convince any manufacturer or carrier of that unless their goal is to please the tech community. This permission serves only to provide an easy way to blacklist apps. The whole point of superuser apps is that the user grants permission EVERY TIME, this is redundant, insecure, and serves no purpose. I wholeheartedly unsupport it and am awaiting the time it is removed.
 
+Adam Outler That is the point I was trying to make. I hate to have to word it this way, but projects like this have gotten so big and gathered such a following that they forget they are "hacking" and "modding" and not real parts of the stock system. If the user didn't realize the application had root access from the popup, they most likely didn't read the list of permissions this was buried in either. Having developer "root" applications, I face enough issues simply explaining that people need superuser access to not have to deal with another swarm who have it and it is unavailable over some vanity permission.
 
i m a b.e. student and working on firewall for android will anyone suggest me where i got some good stuff about android firewall
 
I just made the change on one of my app, sadly Play Store warns even non rooted users about the app having access to all user data which is obviously wrong. So I got many complaints and bad ratings because of that, and decided to remove the permission for now, just to find more bad reviews about the removal!

While all my other apps have this permission declared, I find it quite awful to get such a warning in Play Store when an app is not actually granted the permission just yet and a prompt will get user confirmation.

While I completely agree to the fact of declaring such permission, IMO Play Store should not show it as Android (and Play Store) doesn't actually provide any such access in the first place.
Translate
Add a comment...