NOTICE: This content was originally posted to Google+, then imported here. Some formatting may be lost, links may be dead, and images may be missing.
Almost two years ago, the ACCESS_SUPERUSER permission was coined, and by a select few this was greeted with enthusiasm. I care about compatibility and uniformity, and thus SuperSU also implemented it.
3rd-party-app-defined permissions have never really worked well on Android, and various quirks have caused issues with it before - install-order issues, for example, that could cause the permission to not be granted, which makes it unreliable and requiring odd workarounds. Let's face it, the system is designed primarily for core system packages to declare permissions, and 3rd party packages to only use them.
Furthermore, it's not really useful. There's an optional warning in the root request prompt (disabled by default for some time now in SuperSU), but the permission is not in any way enforced. It does show up in the permissions box when you install an app (in short form), but how often do you install a root app that you didn't already know uses root? And if you didn't know, would perhaps the root prompt itself be enough indication? If someone is trying to be sneaky about it, they will not declare the permission anyway (without any repercussions).
It has always irked me that it used the android.permission space as well, rather than the advised package-name-based space. I've always suspected it would create issues somewhere down the line - and now it has!
Android 5.0 Lollipop now requires custom permissions to be unique unless the declaring packages are signed with the same cryptographic keys (same author, usually), or package installation will fail. As all modern root management packages now declare this permission, this means you cannot easily install a different one and start using that one, as its initial installation will fail, unless you are using a recovery-based installer that also cleans away the old one.
Declaring this permission thus reduces SuperSU's compatibility, and may keep you from upgrading from another package to SuperSU. Not all packages have the friendly option to uninstall themselves and leave a working su binary that allows switching to a competing package like SuperSU does, and removing a system-based root management package may be difficult or even impossible. Having reduced compatibility because of this permission of questionable value is obviously not an option, and thus it will have to go.
Now, there are two major options going forward:
(1) we drop the permission, forget it ever happened, and never speak of it again, or
(2) we rename the permission in SuperSU, and try to convince all root app developers to request yet another permission, again (eventually for each different root management app as well)
I'm open to your opinions on the matter, whether (1) or (2) has your preference, but unless a full blown riot erupts, I doubt I'll be keeping it the way it is now.
If you do not post a reason for your preference, your vote will be ignored. Do not respond if you do not understand what this is about. Neither option kills root!
I'll go with 2
What is your advice?
1 or 2 ?
Fully agree with your arguments and would go for remove it. Any other solution will most likely cause issues down the road again and workarounds are never a solution. And the pros don't outweigh the cons anyway, IMHO.
1 I reread and realized I miss read my apologies +Chainfire
This was the perfect time to use the poll option of Google+
it's like fight club ... never talk about option 2, but do it :D
Ik zou voor 2 gaan! :)
Use the poll option to collect all readers' opinion. I'd go through the 2nd way.
1 - I believe , when rooting your device, it comes with the inherent risk anyway. So, I'm all for less issues down the road
We anyway have to grant super user access to apps, no apps can just automatically grab root, so there is no need for the permission..
1 because you will always be at mercy of Google. Just forget about it and move on. I'm a root app developer with published apps.
From a technical standpoint, it seems 1 would be the best and cleanest option for maximum compatibility and cooperation. Having compatibility with several different root packages can get messy and can actually shut out any new tools coming out as they would have to define their own permission which no apps request. As a non-developer, I don't really know why it's even needed.
In fact, I've run into an app that refused to request su because it couldn't find the Superuser package (I had SuperSU installed). Clearly there are alternatives to verifying this is here.
What is the drawback of option 1? I can't find one, but maybe I'm just not informed of what the implications are. If there are no drawbacks, my vote is 1.
I see no need for this permission anyways. It really is of no use like you said. I'm fin with dropping it and forgetting about it
I am very curious why you would choose option 2 in light of all the drawbacks (going through the exact same issues again as two years ago, the permission system not really being up to it, putting significant extra work-load on root app developers, having no clear benefits, etc). Arguments please.
+Matteo Luigi Riso it was not meant merely as a poll, I will ignore all comments that have no reason for their choice anyway.
I'd vote #1
Dropping it is probably a pretty good idea. I saw a ton of root apps that didn't have the Superuser permission declared in their manifest, so that isn't really vital. And since rooting is more of a advanced-user thing, that wouldn't really be a problem. Even if one has doubts the app has good intentions, just check the log what it is doing.
What the heck, why do you all think 2 is a good idea? You think root app developers will actually add a permission for every root management app rather than just say duck it and not declare anything? Let's just forget about this mess and pretend it never happened.
1, half root apps dont use it, its got the wrong space, and serves no purpose.
1 No need for it. Most root apps mention that it requires root in the Play Store description. Joe Average doesn't bother reading permissions in the first place. Not to mention like you said the app generates a pop-up requesting root access anyways.
- If we go with 2 it would mean that in order to show permission you would need dozens of permissions for different apps.
I say 1 primarily because it gets rid of a lot of issues now and further down the road. Plus if you're rooting your phone you typically know what you're doing.
1 because you really said it! The bad guys will not need that permission.
- Why retro-act all the same BS as before? Can you imagine all the "oes phuks" comments/posts from every uninformed/enlightened user in ALL the possible forums/blogs about how their sh*t just stopped working and dev MUST FIX NOW!!!
AFIK SuperSu is the only Su working almost completely (Nothings 100%) so... This would kind of be a Phu-Q to everyone and "use my sh*t or it won't work right" situation if option 2 was executed?
Could someone who thinks 2 is the best idea explain why?
Y U NO USE G+ POLL?
Oh.. And 1.
1, obviously. I don't think I've ever seen a root app that actually uses the permission.
I love your work man !!
1. what's the point in renaming when we can just do away with it?
I read your text diagonal and I did not understand that.
I thought it would no longer be able to have super su and be rooted if all the dev does not work in the same direction.
What matters is I can always rooted my phone and I can only thank you for the work you do for so many years!
THANK YOU for all your work !!!
sorry for my bad english
1, to avoid potentially ending up in the same position as in now and because 2 would require considerable buy in from developers.
1- I already forgot about it.
Just say bye to every permission
This screams out to use a Google+ Poll...
I vote for option 1.
While declaring a root permission was good for transparency, it's not a security concern as with the other permissions. In contrast to "normal permissions", declaring "ACCESS_SUPERUSER" doesn't necessarily mean that app will get it.
While the initial idea of declaring the permission was well intended, adoption was bad and AFAIK no root managment tool did ever enforce this. As it wasn't enforced, the transparency argument for declaring it is moot, as adoption is not required.
Requiring different permissions (Option2) for the same resource (root access) would just introduce more fragmentation which we already have enough off, especially in the root community.
In a perfect world root access for apps should be transparent, working independently of what root tool is used, while this is already not the case, we should strive to achieve it.
1 because evolution is always good... Why declare a separate permission when we will be the ones granting the app root access in case it asks for it.
So far, nobody voting 2 has actually stated why, and all whom I know to be developers have voted 1. Interesting.
I never realised a practical usability of the permission, anyway.
1 - This seems to be the best answer for less issues in the future
1 will save much hasssle and has no real drawback
Option 2 is the way to go.I think it is officially time that google includes root access on their devices is the Nexus lineup.
+Sayan Goswami Option 2 doesn't have anything to do with Google adding official root access. Read the post again.
+darken +Chainfire IMHO, you two being the most "top-notchiest" Devs I've had the pleasure of using both your hard work (SuperSu PRO, and SD Maid PRO), I believe furthering any consideration for "2" has justifiably been stamped out (unless there's hard argument saying otherwise).
that's all... Carry on! I count on your hard work, quit dawdling on G+... Lol
Who's original idea was it to have this permission system for root apps? +Koushik Dutta ?
Dmn please do 2
+darken I was just suggesting an alternative! Get it?
1 : the root management app already produces a popup which requires action when an installed app requests Root the first time; declaring it in the manifest doesn't seem to add any extra layer of security for me. If you're rooted, you're taking responsibility for keeping track and allowing access to your system, you should already know what apps are root-enabled apps. Even if an average non-rooted user installs a root app, the permission is useless to them (and possibly confusing if they aren't aware of "root").
1. I know I'm bucking the trend here, but #2 sounds like a ton of trouble for little—if any—real gain. To make #2 work, you'd have to set up a registrar of third-party (and root management) apps, which doesn't sound workable, nor likely.
Should have used a poll.
You should've poll this. 2
+Chainfire because developers need to deal with things in pragmatic terms and make their apps just work.
I believe 2 is the best option
If the option 1 means there won't be root in the future that's a no for me, I would go for the option 2 no matter what.
Everyone voting 2 didn't state why... And I'm guessing they did so as far as irrational fear.
Of all the responses I've seen, in addition to what you've stated, +Prem Suraj 's comment was the most important one:
Since SuperSU always prompts before granting access anyway, this permission is redundant - It never really did anything to protect anyone anyway. All it did was maybe give some people an extra warm-fuzzy - but given a choice between "warm fuzzy but broken" and "working" - I'll choose working.
1. If it's causing problems, then just drop it. You are only one developer, who is maintaining SU access management tool up to date, so in my eyes, you can dictate the rules.
I'd say 1 because as I understand it that means greatest compatibility for all root apps and avoiding a similar problem later when/if Google changes something again a couple years down the line. If it's not enforced and there's no punishment for NOT doing it, then as you said, there's any not much point since the sneaky/malicious devs will just hide it anyway. The path #2 leads down sounds like too much ongoing maintenance for very little practical gain.
Clearly, 1 is the obvious choice. Perhaps if it had been implemented correctly in the first place, it would be worth considering finding a way to keep it. But as it is, the permission is only optional for root apps, and most don't even declare it. Let's pretend it never happened.
TBH, root access is a very small component of a typical Android root app. It should be straight forward to obtain and easy to use. Developers have many other things to worry about their apps functionality and bug fixes. Root library should be robust and universal. The last thing a root app developer wants to deal with is compatibility issues with root libraries and more permissions.
Definitely 1, as all the hassle of trying to get loads of other developers to change their apps for no benefit is a distraction you don't need.. Plus as you say, many people saying 1 have given a reason whereas no one saying 2 has, so I think you have your answer!
1... There's no chance I'll be calling it for 5 different root managers in my apps. Each rom has their own usually... So this breaks compatibility. What's the point. Nuke it +Chainfire
I'm getting the impression the 2 votes are spam or trolls. Or they don't understand how this stuff works (one person stated the fear of no more root if it's removed? that's not true...).
- I take comfort in knowing that a developer cares enough to request a permission like SuperSU transparently. Two years ago seemed like a drama but in reality, it really wasn't.
1... Because to often I get the message to grant permission, but after that the app is still searching for SuperSU... (Helium often makes it worse with updates for their app and then chainfire has to fix this, thats not fair and he does great work for all root Users
2 because I think it's easier way to do it
1; I presume the new (ish) Play design doesn't show the permission anyway, and 2 is a nasty horrible hack.
I'm stating that #1 should be the better option. Trying to get every root developer yo adopt #2 will be a hassle and since you are the one that controls the SU side here you should do what's best for you. All in all #1 is better in the long run.
To get rid of all issues, take the 1 - train ;)
- I'd say just remove it... I mean, I generally know when I'm installing a root app, and for sure will know when the su request comes up.
Because 2 could cause one root app don't work with all root daemon, and that's ridiculous, root is root, no matter what daemon is managing the su.
And because it's a waste of time for devs declare one permission for each su daemon.
Oh God, 1 please!
option 1. Ideally all other devs would respect a name change but as we all know they won't, so good sense suggests it has to go to avoid future problems.
Option 1 sounds like the easiest solution, I agree with you that the prompt comes up when an applications attempts to use root so it isn't really necessary if it is going to cause an issue.
- I don't understand the technicality but I always wondered why I would permit when I know I am using the root app for some purpose. I have never denied a permission in my 3 yrs of su usage. Thanks
1 - The SuperSU grant access prompt from a root application is all that it is needed. Like you mentioned, when installing an app from the playstore, as the end-user I already know what I am getting into.
ACCESS_SUPERUSER was a nice idea in theory but never really had any value beyond the purely symbolic. Toss it and don't look back.
1 because 2 is messy - convince all root developers to declare a new permission for each root management app? Never gonna happen.
I don't think we gain anything by the existence of the permission either.
G+ Supports polls btw. Would have been good for this.
+Christopher Cote Yep. The idea originally came from +Koushik Dutta; see https://plus.google.com/103583939320326217147/posts/T9xnMJEnzf1
You have gave the reason -- you got the root prompt already .
If different su declare different permission, as an app developer, which one i should declare?
No. It cause more trouble then it solve
Permissions are for letting the user know what all a certain app is going to access on their phone. While I agree that access_superuser certainly should be a permission, if it is becoming this messy, drop it. And it's anyway a controlled access, unlike other permissions.
What's up with people voting for 2, at least someone state why!
So far, I haven't seen any (valid) arguments for "2".
As for your summary above, +Chainfire: I think it's rather logical than surprising. Why? Kind of like +Paul Reioux said - most developers, most of the times, will obviously rather go for the most efficient and compatible solution. And, (product-specific) workarounds will always be avoided whenever possible.
The top arguments, IMHO, have been named already. No matter of its initial intend, the ACCESS_SUPERUSER permission
1.) in its current implementation is broken (as of 5.0)
2.) is messing in a context where it shouldn't mess around
3.) 's initial intend is obsolete anyways, since adoption wasn't strict and neither enforced.
Thus, its neither logical nor economical to reimplement it. And, IMHO, this is exactly how probably any developer evaluates the situation. And, in return, this is why all devs so far voted "1".
PS: Sorry for my lack of English, but I hope you got what I mean.
1 as you said (+Chainfire) "neither options kills root" and is simpler to forget about that permission; and in both ways some developers have to change something.
2 All the way
Is there an option 3 - have all su packages signed with same key?
I never saw a good reason for this to exist, so number 1.
Since the user is always prompt to permit or not (at least once), the permission only gives useless redundancy.
I've never been a fan of the permission and have thus far avoided adding it to Nova Launcher with only like 2 requests from users to add it. For an app that absolutely requires root it'd actually make more sense to have a uses-library so non-rooted devices can't even install/rate the app (though maybe adding a library would be hard for some types of root?). For an app like Nova Launcher, which barely uses root at all*, declaring the permission is misleading as users would expect root to be required and wonder why a launcher needs it. Having the prompt when they activate an option that needs it is a much better experience.
I also would not want to be chasing down the different permissions for the different superuser apps and it potentially creates a form of lockin as a new superuser app either doesn't require the permission so it might be perceived as less secure, or it requires it and no apps support it.
- In Nova there is an option to hide the status bar clock that requires root. It's off by default. It also can be used for widgets in the drawer on Android 4.0, but it's not needed in 4.1+ which is where most users are.
- I never cared about the permission anyways because I think it is pointless. I normally know what I'm installing and if an App wants root without telling me SuperSU is going to ask me for root anyways.
- Serves no real purpose, most root apps don't use it anyway, and 2 has the possibility for more problems down the road.
2 for me
I say 2. If you go with option 1, how do you deny permissions? I don't want any app automatically gaining root.
What if I want an app to have root for 15 minutes? Does option 1 change the way su works right now?
I remember on the s3,s4, some of the Verizon apps started to ask for root permissions. The way su works right now I was able to ignore it. If you go option 1, the Verizon apps would have gotten root access.
There's a lot of popular root apps that don't request it so there's no point making things more complicated for something that isn't very popular anyway. I don't mean offence to +Chainfire, but SuperSU isn't the only root management app out there (its the one I use) but there's also superuser as well as the one built into CyanogenMod and Paranoid Android etc. If it was a more popular feature then it would be worth the time but for now it isn't.
- It's nice to have the option to use it, even if you personally won't. Also, it'll be nice to see what developers no longer care about their apps when they don't get updated.
1 the notification of supersu / other apps is sufficient to me
I would've liked that in some distant future the root dialog would not pop up if the app declared the permission. This is just how permissions work.
In favour of that: Let's try option 2 until Android 6. ?
Maybe enforce the use of the permission starting 1.1.15?
That's enough time for those devs who update their apps. Those who don't won't do it in two years.
Of course 1
ACCESS_SUPERUSER is only good to know that the app uses root. It isn't worth the problems it causes.
1 seems the easiest way to me.
Dear +Chainfire, firstly immense respect for your diligently consistent efforts for transparency in development. Imo 1 is a better option because there are many apps for which root devs may not continue development or dormant projects.
In the present scenario it is definitely a sane choice to forget it.
You're going to find out when it requests root (in the skin chance you didn't already know)
1, the second option would require every developer that would like to use root to declare permissions for every root management. If the root management asks for root with a popup is enough and very close to a declared permission.
I vote 2. From a business security perspective, permissions are imperative.
I can't see the downside of option 1, but 2 would create a lot of hassle, require other devs of root apps to buy in to this way of doing things, and generally create a mess.
So I vote for the cleanest, simplest option: 1. But what are the downsides of option 1, because I can't really see one??
Maintaining this permission set would be awesome, if root developers actually used it. I think getting rid of it altogether isn't necessarily a bad thing, but it does help some users who root their devices but still install apps that maliciously attempt root access.
I think that going with 2 would be a good option, but only if you move toward applying this permission check by default. In fact, if you go with option 2 it would probably be best to force users to flash a zip or something (make it slightly more difficult) to skip this permission check. I say that because if it's enforced on the majority of devices, it will force root apps to add the permission request. Otherwise it ends up at this same point and nothing happens (just an extra permission that app developers ignore).
I really think this is a good idea, especially since so few users pay enough attention when they get the root warning.
Personally, I think my interpretation of option 2 is too much work and to relies on developers paying along.
Option 1 makes the most sense. The pop up notifies users of the root request, and most users know when an app requires root.
Absolutely (1). Root users never needed a permission to know that an app makes use of Root calls, it actually proved to be a bit confusing to some users demanding us developers to add that permission without actually knowing why and what for. Just forget that it ever happened, we couldn't care less about that crap.
+Paul Reioux does have a point, we should focus on app quality and not on some weird ass Root compatibility as it's something implicit when using Root apps.
Kill it with fire.
- App developers shouldn't need to add a permission for every single su app. This will just prevent any new su app ever being possible or worse different apps forcing the use of a specific su app.
I'm going with option 1. It's unnecessary to have that permission. And, not all developers are willing to update their app for this. Some app that are actually good, don't have an active dev behind it to support it with updates.
+Chainfire I suspect many of the votes for #2 are from folks skimming the original post and thinking choice #1 == no root access.
+Seamus Wise I don't know of a single business that allows rooted devices.
And you seem to be forgetting that SuperSU prompts you before actually granting root access to an app. That prompt is NOT going away - only the redundant "permission" which never really worked/did much in the first place.
1, because of what you wrote yourself between "further more, it is not really usefull" and "without repercussions". I've wondered about the usefulness of this permission since kouch proposed it and just considered it good manner ever since, nothing more.
- The reasons have been said already. It makes no sense that every app using root would need to add permission for every root app.
Tallying up: every commenter of which I know they are actually a developer has voted for removal; aside from that, for the voters actually giving reasons for their vote, the removal votes easily win from the renaming votes. Consider the permission removed. Case closed.