On Motorola RAZR i updating su binary after choosing simply install (not recovery) lead to placing arm version of su in /system/xbin.
I was previously on ChainsDD superuser and install version 1.0.1.5 from Play Store. First launch obviously wanted to update binary but did it wrong way. Hopefully I had some su binary backed up on the device and was able to restore root through adb shell. Without this I would loose root.

EDIT. I mean I placed your x86 su binary taken from APK, place in proper place, chmod it and everything is working since then.

When an app requests superuser rights, SU will only allow the user to grant those after a countdown of ~5 seconds. Sometimes apps are impatient and they think their request was denied. Could you implement an option for advanced users to disable the waiting period, so that we can grant rights immediately?

EDIT: One example is "920 Text Editor", which asks for su rights repeatedly because of the delay. This app is very "impatient" and I would say the problem lies on its side, but an option to disable the delay in Superuser would solve these quirks with all impatient apps ...

Thanks for creating another amazing app! :)
What license does this code have?

Start Superuser, Applist contains some apps that have been granted su permission.
Press Home Button.
Launch another app thats not yet on the granted list, confirm Superuser request (permanently).
Press Home Button.
Start Superuser via Recent Apps List - the new App is not there yet.
Swipe away Superuser from the recent Apps List, start Superuser.
Now the List contains the new App.

Reproduced this several times by clearing all granted Apps.

Superuser 1.0.0.7
Nexus 4, JDQ39

maguro stock yakju.

Reboots into recovery, and ends up with the sad lying android with red exclamation mark.

power+vol up

shows checking signature, installation aborted.

1.0.0.6 was installed using recovery zip.

I installed superuser and when I open it ; it says that the binary su must update and when I choose install there is an error that prevent installion to be completed and I don't know what error it is . Please help me

This ability is more useful for debugging, so every one know which app runs what command.
Sorry for bad English.

As soon as someone commits a patch to the translations according to the requested way CyanogenMod Gerrit croaks:

fatal: Not a git repository (or any parent up to mount point /home)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
sh: 1: cd: can't cd to Superuser

Where do you file a bug report for the CyanogenMod build environment?

With SuperSU's su: [CODE]su -c make me a sandwich[/CODE] makes me a sandwich.
To make a sandwich with the included su: [CODE]su -c "make me a sandwich"[/CODE]

Would be nice if either worked.
I'll wrap my head around the arg handling and pull request this modification if I find time to.

You the man, Koush

Superuser does not save details of any app approved while pin protection is enabled. Logging is not affected.

I just built from Git and installed on Galaxy Nexus Stock 4.2.2.

All settings seem to work except PIN-protection. Nothing happens when I click the option. Logcat doesn't show anything.

Am I missing something?

Model number: Nexus 4
Android version: 4.3
Baseband version: M9615A-CEFWMAZM-2.0.1700.84
Kernel version: 4.3.0-perf-gf43c3d9 [email protected] #1 Mon Jun 17 16:55:05 PDT 2013
Build number: JWR66V

I'm sure you're already aware, but I couldn't see an issue logged so I thought it might be an idea to add it.

What works:

• adb shell is able to obtain root access using the 'su' binary
• Superuser.apk is able to install itself if an insecure 'su' binary is installed.

What doesn't work:

• Any app trying to obtain root access, including Superuser.apk.

Other info:
The changes appear to be identical to the ones in the leaked GE images. I can confirm that SuperSU v1.41 (by Chainfire) which I believe was designed for GE Devices works successfully on a clean install Nexus 4, Nexus 7 (2012) and Nexus 10 (despite some users claiming it doesn't)

Please add possibility to install Superuser on Android 2.1 Eclair devices (and older versions, if possible).

Maybe someone can think that "Eclair is too old", "Eclair is not supported even by Google - no Google Play updates" and "New phones have at least Gingerbread now". But even now, people are deciding to buy older, but cheaper devices to have possibility to use Android. Custom ROMs have serious bugs, so it's bad to use them as "daily driver". (Even me, Android enthusiast, I am using Eclair, because don't want 4hrs battery life, or low performance.)

Superuser app is Froyo+ only, so when people are using stock ROMs, they must install obsolete ChainsDD's Superuser, or SuperSU that torments user with toasts like "Granted SU rights for XXXXXX. Please consider buying Pro version". And both SUs are not open source, as you know.

So, please add possibility to download and/or build Eclair Superuser's version. I know there may be not possible to apply Holo theme, or some other goodies, but please try to give SU freedom for older phones!

But I'll leave it to someone who actually understand the text:

.//Superuser/res/values-zh/strings.xml: 超級使用者的二進制檔案（su）一定要更新\n\n請選擇安裝方法\n\HTC 設備建議選擇回復模式（Recovery）的安裝方法
.//Superuser/res/values-zh-rHK/strings.xml: 超級使用者的二進制檔案（su）一定要更新\n\n請選擇安裝方法\n\HTC 設備建議選擇回復模式（Recovery）的安裝方法
.//Superuser/res/values-zh-rTW/strings.xml: 超級使用者的二進制檔案（su）一定要更新\n\n請選擇安裝方法\n\HTC 設備建議選擇回復模式（Recovery）的安裝方法

When an app doesn't have the permission to use SU, it pops up the window asking if you want to allow, and it gives the options "just once, for 10 minutes, or forever". This works fine until you use pin protection.

As soon as I enabled pin protection, it would pop-up this dialog every time an app requested SU access, even if I've already added it to the "forever" list. (This was especially annoying when using an app to backup my apps and their data.)

Issue occurred on a Nexus 10, running 4.2.2 stock.

I compiled Superuser in to the settings app on AOSP 4.2.2 for Mako (Nexus 4) and it's not working. I can su in ADB and get root, but nothing else can. The settings integration seemed to go fine, I don't get any force closes or anything. I cherry-picked patch set 5 from CM.

Things I've done:

• Removed the default su app from the source tree as it causes a name conflict
• Added su as package to be included with the build
• Verified that the su binary works and is the one from this source and not some other project. I hex dumped it and found strings referenceing "koush" and "com.android.settings".

Not sure where to go with this, so I uploaded a logcat dump here. Towards the end I opened Titanium Backup and let it try to get root, so there's something to look for. I can't really make sense of it, it's so noisy.

If you need any more info just let me know, I love this app. Thanks.

In 1.0.0.6.

Start superuser. Press home. Start again. Select a granted app. Now I have two icons for log and no trash icon in the action bar.

I've recently tried to clear data from superuser (basically reset what has access and all my superuser settings) and I've discovered I cannot do that in cm10.1 with the built in superuser.

I agree with your mindset that superuser should be integrated into settings, but im looking at apps like Nova launcher, that also integrate a menu option into settings called launcher (which replaces the link to trebuchet) and it still functions separately. updates can come from the market, there is an icon to launch the app, there is an app listed in the all apps menu of settings so I can clear the data if something goes wrong, etc.

please consider this approach rather than having the baked in cm superuser and the superuser on the market be separate.

another thing this would clear up is if someone on cm currently installs the superuser from the market they are prompted to install the binary to run with the app, which disables the baked in superuser, and there's no way to switch back without reflashing the nightly.

being as the market superuser has a dark theme built in, it would essentially provide the same end user experience (as far as how it will be visually presented and how it will operate).

Mounting the system and/or writing/deleting files from /system will cause the Sony Xperia Z to reboot when the bootloader is locked.

The same issue is present for SuperSU, whereas the old Superuser app by ChainsDD does not have this problem.

Running su command causes a segmentation fault.

I have a Nexus One, running MIUI 2.3.0.

I have managed to build the source, using printf and fflush doesn't show where it is dying, so I have put a return statement before each method call to see where it is dying and I'll go and remove each one to see what line/method call where it is dying.

My C isn't great, haven't done it in a fair few years, so if there's anything I can do to help make this a better issue report, please tell me.

Cheers.

An option to temporarily unroot for a period of time, until the user toggles it again, or for specific applications. Having it as an intent would make it Tasker compatible.
Or if it is possible to hide su from certain applications (Wallet and some video apps for example) would achieve a similar goal.

Right now the app is set to Holo Light and before it was using Holo Dark, which looks much better IMHO.

Could you please make a toggle in the GUI between the two?

Even if this seems as trivial as a regular playstore installation, it would be nice to provide some hints on how to safely migrate from other utility to this one (chainsdd's / SuperSU / ...)

How valuable would be this post? http://forum.xda-developers.com/showpost.php?p=39831040&postcount=2701

Just flashed superuser.zip. After booting I started Superuser once to check that the process worked (coming from SuperSU).

Then I started Titanuim Backup and got a white screen (Superuser Actionbar visible, there was a short glimpse of the actual confirmation screen but it immediatly turned white).

After pressing Back and restarting Titanium all went as expected, got the Superuser confirmation screen showing up.

It would be a great security enhancement if the superuser app asked for the lock pattern/pin/password when granting superuser permissions. Just like sudo on Unix. At least as an option.

I've noticed almost all other SU apps list their apps alphabetically where this one lists chronologically based on when the initial request was made. I'm wondering the pros/cons of each?

I'd easily say a pro for alphabetical is organization.

Would it be considered to switch this app to alphabetical?

I think it would be a nice feature if there was a predefined and supported way for the embedded Superuser build to override the CyanogenMod-specific behavior in su.c. For example, I forked Superuser just to change access_disabled() so that my non-CM-based ROM could take advantage of the Superuser Access setting. I also removed the bit about ro.debuggable needing to be set to one, ignored the build type, etc. All very minor changes that are specific for that code to work with my particular builds, but ultimately I still had to fork the repo to accomplish it.

Perhaps something as simple as breaking out the CM-specific bit(s) into their own C file and allowing for an override to that file be specified with a build property? Developers could then decide how they can best implement those function(s) for their device/build without needing to completely ape the CyanogenMod code. It may even lend itself as being useful for additional device/build specific edits if any become common in the future.

Thanks for the consideration, and more importantly thanks for making your excellent work here free and transparent for all to benefit from, it's greatly appreciated!

I have a rooted Samsung S3 SGH-T999 and now when an app I am developing crashes (unhandled exception on main looper), then Android's built in App Crash Reporter seems to deadlock and Watchdog will eventually kill the system process and the device will reboot.

I have duplicated this issue on both koush's Superuser and chainsdd's Superuser, however this issue does not happen with chainfire's SuperSU.
When I remove su or use chainsdd's Superuser temp un-root, the issue does not happen, this leads me to believe the issue is related to how Debug.saveDumpstate behaves when su is present.

As you can see from the anr/traces.txt below, several threads are waiting on ActivityManagerService to Debug.saveDumpstate. But Debug.saveDumpstate is native and I am unsure about how to debug the issue in libandroid_runtime.so.

Duplication:
Cause an app to crash, I used the simple Activity linked below.

Expected behavior:
The app should exit and I should see an alert dialog "Unfortunately, [app name] has stopped.".

Actual behavior:
The system hangs on a black screen with an unresponsive notification bar, the phone reboots after 2 mins.

logcat from crash to reboot = https://gist.github.com/will-quast/5489543
anr/traces.txt from Watchdog dump = https://gist.github.com/will-quast/5489550
simple app to cause app crashes = https://gist.github.com/will-quast/5489568

Model = SGH-T999
Android = 4.1.1
Baseband = T999UVDLJC
Kernel = 3.0.31-370274 se.infra@SEP-80 #1
Build = JRO03L.T999UVDLJC

I have SuperSU when I try to update su binary so that I can use superuser it fails to update su binary

here is the logcat http://pastebin.com/qPSN4VdP

I hope this will be fixed soon

Would it be possible for you to add dedicated branches for building Superuser for Android 4.1?
I included SuperUser into CM10, but had to fix a couple issues:

koush/Superuser/Superuser/src/com/koushikdutta/superuser/Helper.java

• all references to android.os.UserManager

koush/Widgets/Widgets/res/layout-large/container_activity.xml:

• layout_marginEnd
• layout_marginStart

koush/Superuser/Superuser/res/layout-land/log_item.xml

• paddingEnd
• paddingStart

Voodoo OTA rootkeeper already does this: https://github.com/project-voodoo/ota-rootkeeper-app

What would be nice is an implementation where Superuser silently keeps a copy of it's su binary in another place than /system/xbin. After an OTA the su binary will be stripped of it's execute bit.

Could you then use the extra copy of su to re-root?

Then Superuser would be self contained and could detect a loss of root due to OTA and fix it.

Since it's a copy of Superuser's su, the version och checksum can be checked to see that the copy hasn't been tampered with.

I've been using clocksync for NTP sync.

Recently I noticed that it takes a lot of time for it to get root when you select synchronize. I tried to get around it by deleting it from the list in Superuser.

Now it still synchronizes time (which requires root) and the Superuser dialog does not show up.

https://play.google.com/store/apps/details?id=ru.org.amip.ClockSync

Badly behaving Superuser request in the app could possibly account for the slow request, but it should not be able to get superuser access after being removed from the list.

I updated SuperUser some hours ago. Jost now an app requested su and the dialogue popped on. Clicking Deny or Allow showed the Toast. SuperUser tried to return to the requesting app, but immediately popped back, asking again if I want to grant su access. I couldn't return to the app.

I had to manually open the Superuser app and then got a prompt that the binary is outdated.

I'm wondering if it's feasible to put this check in the su request dialogue.

Edit: I just noticed, that there was a notification that told me to update su, but I'm not sure when it came up since i didn't notice it.

Is it supposed to support an unrooted device with the beta installed? If not supported, a better error message should be given.

I start the app and it wants to update the su binary. Choose recovery.

adb logcat:

I/ActivityManager( 393): START u0 {act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] flg=0x10200000 cmp=com.koushikdutta.superuser/.MainActivity bnds=[360,567][360,567]} from pid 718
I/ActivityManager( 393): Start proc com.koushikdutta.superuser for activity com.koushikdutta.superuser/.MainActivity: pid=2234 uid=10137 gids={50137, 1028}
W/System.err( 2234): at com.koushikdutta.superuser.MainActivity.checkSu(MainActivity.java:227)
W/System.err( 2234): at com.koushikdutta.superuser.MainActivity$6.run(MainActivity.java:252)
I/ActivityManager( 393): Displayed com.koushikdutta.superuser/.MainActivity: +852ms
W/System.err( 2234): at com.koushikdutta.superuser.MainActivity$2.run(MainActivity.java:123)

Right now you can only change the PIN to a new one once is set, but you can't remove it.

On AOSP OpenMaster (Android 4.2.2.2.2.2.2.2.2.2), SuperUser requests are always denied and no prompt is displayed. I have attempted a superuser request with the default settings in the Superuser app and after modifying them (Allow requests from all users; allow requests by default).
A dialog never appears to Deny/Allow the request, just automatic denial when any app attempts a superuser request, however shell requests succeed without an issue.

The following is a snippet from a logcat on grouper using ROM Manager to flash a recovery on AOSP OpenMaster.

W/su ( 8090): request rejected (10076->0 . /data/data/com.koushikdutta.rommanager/files/rommanager.sh) D/su ( 8087): su invoked. E/su ( 8088): chown (/dev/com.koushikdutta.superuser, 10032, 10032) failed with 1: Operation not permitted

I have tested many variations of this, but this is the latest situation. Flash superuser.zip via clockworkmod.com in recovery: all is well.

Then, build the app with a different package id by using aapt in the build.xml with the same flags as in Superuser/Android.mk. Flash in recovery, restart and start Superuser: says the su is out dated. Install su and "Install: There was an error installing Superuser":--------- beginning of /dev/log/main D/SurfaceFlinger( 103): Screen about to return, flinger = 0x41b7caf0 V/Sensors ( 280): handle : 14 en: 1 mEnabled:00000000 V/Sensors ( 280): sensor state change what=14 V/Sensors ( 280): enabled_sensors: 16384 dmp_started: 0 V/Sensors ( 280): Starting DMP --------- beginning of /dev/log/system I/WindowManager( 280): No lock screen! I/ ( 280): mpu3050_resume: Resuming to 0070 V/Sensors ( 280): set fifo rate: 39 200000000 I/ ( 280): mpu3050_suspend: suspending sensors to 0000 I/ ( 280): mpu3050_suspend: Will resume next to 0070 I/MPL-ml ( 280): Actual ODR: 25 Hz I/ ( 280): mpu3050_resume: Resuming to 0070 V/Sensors ( 280): set fifo rate: 13 66667000 I/ ( 280): mpu3050_suspend: suspending sensors to 0000 I/ ( 280): mpu3050_suspend: Will resume next to 0070 I/MPL-ml ( 280): Actual ODR: 25 Hz I/ ( 280): mpu3050_resume: Resuming to 0070 D/jp.co.qsdn.android.jinbei3d.setting.Prefs( 446): 2131034131 = getCameraMode() D/dalvikvm( 280): GC_FOR_ALLOC freed 879K, 32% free 6346K/9287K, paused 63ms, total 63ms E/PowerManagerService( 280): Excessive delay setting brightness: 209ms, mask=2 D/dalvikvm( 446): GC_CONCURRENT freed 1775K, 48% free 4401K/8451K, paused 8ms+3ms, total 49ms V/tiny_hw ( 106): out_write(0x40d7c540) opening PCM(0), card,dev: 0,0 D/dalvikvm( 486): GC_EXPLICIT freed 744K, 37% free 5327K/8451K, paused 2ms+3ms, total 32ms I/ActivityManager( 280): START {act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] flg=0x10200000 cmp=org.gerry.superuser/com.koushikdutta.superuser.MainActivity u=0} from pid 486 D/dalvikvm( 280): GC_FOR_ALLOC freed 345K, 30% free 6517K/9287K, paused 44ms, total 44ms I/dalvikvm-heap( 280): Grow heap (frag case) to 15.686MB for 1048592-byte allocation D/jp.co.qsdn.android.jinbei3d.setting.Prefs( 446): 2131034131 = getCameraMode() I/Superuser( 744): Result: 6 com.koushikdutta.superuser W/System.err( 744): java.lang.Exception: unknown su W/System.err( 744): at com.koushikdutta.superuser.util.SuHelper.checkSu(SuHelper.java:17) W/System.err( 744): at com.koushikdutta.superuser.MainActivity$7.run(MainActivity.java:274) D/su ( 995): su invoked. D/dalvikvm( 446): GC_CONCURRENT freed 1745K, 48% free 4401K/8451K, paused 3ms+3ms, total 24ms D/libEGL ( 744): loaded /system/lib/egl/libEGL_tegra.so D/libEGL ( 744): loaded /system/lib/egl/libGLESv1_CM_tegra.so D/libEGL ( 744): loaded /system/lib/egl/libGLESv2_tegra.so D/OpenGLRenderer( 744): Enabling debug mode 0 I/ActivityManager( 280): Displayed org.gerry.superuser/com.koushikdutta.superuser.MainActivity: +1s2ms E/tiny_hw ( 106): out_write(0x40d7c540) PCM(0) failed: -32 E/tiny_hw ( 106): out_write(0x40d7c540) PCM(0) failed: -32 V/tiny_hw ( 106): out_standby(0x40d7c540) closing PCM(0) V/tiny_hw ( 106): out_write(0x40d7c540) opening PCM(0), card,dev: 0,0 W/System.err( 744): java.lang.Exception: non zero result W/System.err( 744): at com.koushikdutta.superuser.MainActivity$3.run(MainActivity.java:181) D/su ( 1003): su invoked. E/su ( 1005): stat /data/data/com.koushikdutta.superuser failed with 2: No such file or directory W/su ( 1007): request rejected (10036->0 /system/bin/sh) D/AndroidRuntime( 1008): D/AndroidRuntime( 1008): >>>>>> AndroidRuntime START com.android.internal.os.RuntimeInit <<<<<< D/AndroidRuntime( 1008): CheckJNI is OFF D/dalvikvm( 1008): Trying to load lib libjavacore.so 0x0 D/dalvikvm( 1008): Added shared lib libjavacore.so 0x0 D/dalvikvm( 1008): Trying to load lib libnativehelper.so 0x0 D/dalvikvm( 1008): Added shared lib libnativehelper.so 0x0 D/AndroidRuntime( 1006): D/AndroidRuntime( 1006): >>>>>> AndroidRuntime START com.android.internal.os.RuntimeInit <<<<<< D/AndroidRuntime( 1006): CheckJNI is OFF D/dalvikvm( 1006): Trying to load lib libjavacore.so 0x0 D/dalvikvm( 1006): Added shared lib libjavacore.so 0x0 D/dalvikvm( 1006): Trying to load lib libnativehelper.so 0x0 D/dalvikvm( 1006): Added shared lib libnativehelper.so 0x0 D/AndroidRuntime( 1008): Calling main entry com.android.commands.am.Am W/PackageManager( 280): Removing dangling preferred activity: ComponentInfo{com.android.browser/com.android.browser.BrowserActivity} I/ActivityManager( 280): START {act=android.intent.action.VIEW dat=http://www.clockworkmod.com/superuser/install.html flg=0x10000000 cmp=android/com.android.internal.app.ResolverActivity u=0} from pid 1008 D/AndroidRuntime( 1008): Shutting down VM D/AndroidRuntime( 1006): Calling main entry com.android.commands.am.Am D/dalvikvm( 1008): GC_CONCURRENT freed 98K, 81% free 492K/2560K, paused 1ms+0ms, total 19ms D/AndroidRuntime( 1006): Shutting down VM I/AndroidRuntime( 1006): NOTE: attach of thread 'Binder_2' failed D/dalvikvm( 1006): GC_CONCURRENT freed 100K, 81% free 499K/2560K, paused 1ms+0ms, total 6ms D/dalvikvm( 280): GC_CONCURRENT freed 510K, 24% free 8140K/10695K, paused 4ms+5ms, total 72ms I/ActivityManager( 280): Displayed android/com.android.internal.app.ResolverActivity: +177ms E/tiny_hw ( 106): out_write(0x40d7c540) PCM(0) failed: -32 E/tiny_hw ( 106): out_write(0x40d7c540) PCM(0) failed: -32 E/tiny_hw ( 106): out_write(0x40d7c540) PCM(0) failed: -32 E/tiny_hw ( 106): out_write(0x40d7c540) PCM(0) failed: -32 V/tiny_hw ( 106): out_standby(0x40d7c540) closing PCM(0)

build.xml: <target name="-package-resources" depends="-crunch"> <exec executable="${aapt}" failonerror="true"> <arg value="package" /> <arg value="-f" /> <arg value="-M" /> <arg path="AndroidManifest.xml" /> <arg value="-A" /> <arg path="${asset.absolute.dir}" /> <arg value="-F" /> <arg path="${out.absolute.dir}/${resource.package.file.name}" /> <arg value="-I" /> <arg path="${android.jar}" /> <arg value="-S" /> <arg path="${resource.absolute.dir}" /> <arg value="-S" /> <arg path="${android.library.reference.1}/res" /> <arg value="--extra-packages" /> <arg value="com.koushikdutta.widgets" /> <arg value="--auto-add-overlay" /> <arg value="--rename-manifest-package" /> <arg value="org.gerry.superuser" /> </exec> </target>

Superuser

Switch device language to slovak, then open app in portrait mode, scroll a bit in logs a bit and you should see ungly black line on right..
http://devpic.net/di/KK93/Screenshot_2013-04-02-09-18-29.png

Trying to updating the su binary fails on my rooted HTC Nexus One.
I'm using the stock 2.3.6 ROM and recovery so cannot use the alternative method.

It used to work before the last Superuser updates from Google Play.

Here's the logcat:

E/su      ( 1464): sudb - Opening database
E/su      ( 1464): sudb - Database opened
E/su      ( 1464): sudb - Database closed
D/su      ( 1464): 10083 com.koushikdutta.superuser executing 0 /system/bin/sh using shell /system/bin/sh : sh
I/TelephonyRegistry(  102): notifyServiceState: 0 home F SFR (N/A) 20810  UMTS CSS not supported -1 -1RoamInd: -1DefRoamInd: -1EmergOnly: false
I/TelephonyRegistry(  102): notifyDataConnection: state=2 isDataConnectivityPossible=true reason=null interfaceName=rmnet0 networkType=3
I/Superuser( 1211): Result: 3.0.3
W/System.err( 1211): java.lang.Exception: unknown su
W/System.err( 1211):    at com.koushikdutta.superuser.util.SuHelper.checkSu(SuHelper.java:17)
W/System.err( 1211):    at com.koushikdutta.superuser.MainActivity$3.run(MainActivity.java:177)

Here's the gist for it... hopefully this helps bro....

https://gist.github.com/itsmikeramsay/5083285

I just ran "cppcheck" on the code, and it found a potential problem:
[Superuser/jni/su/su.c:177]: (error) Uninitialized variable: mode

The relevant code is below. What I do not understand is:
the "last" variable.
It looks for me that way:

• because "mode" is uninitialized, "last" can have any value

Maybe "mode" should be initalized and / or be static.
(Otherwise I cannot image how could it have meaningful data at the line where "strlen" is used on it.)

It also would be nice somehow protect against buffer overrun.
Imagine that: "mode" is uninitialized, there is no '\0\ in the first 12 bytes, so the ' mode[last]=' will write out from the area.
So last<=11 would be a nice check also.
(It could change to a fallback solution, if last>11.)

The relevant parts on the su.c file:

int ret = MULTIUSER_MODE_OWNER_ONLY;
char mode[12];
FILE *fp;
if ((fp = fopen(REQUESTOR_MULTIUSER_MODE, "r"))) {
    int last = strlen(mode) - 1;
    if (mode[last] == '\n')
        mode[last] = '\0';
    fgets(mode, sizeof(mode), fp);
    if (strcmp(mode, MULTIUSER_VALUE_USER) == 0) {
        ret = MULTIUSER_MODE_USER;
    } else if (strcmp(mode, MULTIUSER_VALUE_OWNER_MANAGED) == 0) {
        ret = MULTIUSER_MODE_OWNER_MANAGED;
    }
    else {
        ret = MULTIUSER_MODE_OWNER_ONLY;
    }
    fclose(fp);
}
return ret;

I built from source (including latest commit 6b8c7a1) and got an FC:

I/ActivityManager( 389): START u0 {act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] flg=0x10200000 cmp=com.koushikdutta.superuser/.MainActivity bnds=[190,850][360,1050]} from pid 711
I/ActivityManager( 389): Start proc com.koushikdutta.superuser for activity com.koushikdutta.superuser/.MainActivity: pid=2595 uid=10143 gids={50143, 1028}
E/AndroidRuntime( 2595): java.lang.RuntimeException: Unable to start activity ComponentInfo{com.koushikdutta.superuser/com.koushikdutta.superuser.MainActivity}: android.content.res.Resources$NotFoundException: String resource ID #0x7f060014
E/AndroidRuntime( 2595): at com.koushikdutta.superuser.MainActivity.onCreate(MainActivity.java:72)
W/ActivityManager( 389): Force finishing activity com.koushikdutta.superuser/.MainActivity
W/ActivityManager( 389): Activity pause timeout for ActivityRecord{426c9a08 u0 com.koushikdutta.superuser/.MainActivity}
I/ActivityManager( 389): Process com.koushikdutta.superuser (pid 2595) has died

or either please help me understand how to compile it (if possible) in windows?

when i turn the orientation of my devices screen while on the settings page, it goes to the allow/deny main page...

In su.c there is a duplicate:

include pwd.h>

Not sure if this is a real issue or not, but I noticed it while skimming the code.

Regardless that i have it set to prompt, and also have a pin enabled, i managed to find an app that automatically grants itself su permissions. SU is logging it, but doesn't have it on the allow/deny list...

APK: http://code.google.com/p/android-wifi-tether/downloads/detail?name=wifi_tether_v3_3-pre2.apk&can=2&q=

I see there are some guards to prevent dumpstate spamming su requests..

// dumpstate (which logs to logcat/shell) will spam the crap out of the system with su calls
    if (strcmp("/system/bin/dumpstate", ctx->from.bin) == 0)

however I suspect there may be another case, see following screenshots.

https://lh4.googleusercontent.com/-FiihmsoR4kw/UeaIXVLRqDI/AAAAAAAAAWw/b1h9vT_-vpc/w480-h800-no/Screenshot_2013-07-10-17-58-22.png

https://lh4.googleusercontent.com/-k2K9YJlKpmM/UeaIa6bvfRI/AAAAAAAAAW4/evLmnhSP1vQ/w480-h800-no/Screenshot_2013-07-06-18-01-56.png

Background:

• This was observed on the March 10th, 2013 CyanogenMod 10.1 nightly with cooked in koush-superuser.
• It concerns applications that are not in the ALLOW list.

Issue:
Granting an application (Terminal Emulator in this case) superuser permissions with the option "Remember choice for 10 minutes", then rebooting the phone before those 10 minutes are up results in the continued ability to launch the application with root permissions until the full 10 minutes is complete. I can see how this could be argued as simply the way superuser handles the feature, but I also feel like the majority of users would expect the behaviour of a temporary option such as this (especially when relating to security), to reset itself when the devices is restarted. That said, if it seems like anyone might want to continue using the current behaviour, maybe a setting for "temporary permissions to persist across reboots" could be a nice compromise?

Aside from this however, koush/supersu is fantastic so far, and i look forward to using it as it continues to grow-- thanks for your time and the great work!

The log button continues in the action bar when you are seeing the logs