android 4.2+ seteuid (root) failed with 13

[ByteSecurity]

shell@android:/ $ ls -l /system/bin/su
ls -l /system/bin/su
-rwsr-sr-x root root 311900 2013-11-13 14:50 su
shell@android:/ $ su -v
su -v
su invoked.
13 com.koushikdutta.superuser
shell@android:/ $ su
su
su invoked.
stat /data/data/com.koushikdutta.superuser failed with 2: No such file or direct
ory

seteuid (root) failed with 13: Permission denied

How to Solve It?

[nfllab]

I have the same problem. I'm an inexperienced rooter who installed unofficial CWM recovery on stock Samsung GT-I9295 (Galaxy S 4 Active) JDQ39.I9295XXUAMI2 (Android 4.2.2). I downloaded and installed http://download.clockworkmod.com/superuser/superuser.zip (1.0.2.2). When I start su in adb shell, it returns 1. When I start an app that needs root it doesn't get it. The Superuser UI never pops up. Here are the log entries:

D/su (17646): su invoked.
D/su (17647): Allowing shell.
E/su (17648): seteuid (root) failed with 13: Permission denied
D/su (18021): su invoked.
D/su (18022): /dev/com.koushikdutta.superuser/.socket18020
E/su (18024): seteuid (root) failed with 13: Permission denied

Issue #193 seems to be the same, too.

[nfllab]

As a workaround I forced installing su daemon and changed su file mode to 755 in update-binary script. Works for now.

[nfllab]

FYI new su binary never attempts to use daemon if API level is below 18, so the above workaround no longer works.

[koush]

The su daemon should only be necessary in 4.2+, but I can backport.

[nfllab]

Do you mean 4.3+? Whatever the problem is, the zip doesn't work on my phone.

I thought the restriction is through the capability bounding set, but reading /proc/self/status from an app doesn't confirm that:
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000
CapBnd: ffffffffffffffff

And SELinux is permissive.

[koush]

Er yes 4.3+

[cernekee]

The Galaxy S4 Active kernel contains an extra bit of lameness that can cause the set*id() syscalls to fail:

#if defined CONFIG_SEC_RESTRICT_SETUID
int sec_check_execpath(struct mm_struct *mm, char *denypath);
#if defined CONFIG_SEC_RESTRICT_ROOTING_LOG
#define PRINT_LOG(...)  printk(KERN_ERR __VA_ARGS__)
#else
#define PRINT_LOG(...)
#endif  // End of CONFIG_SEC_RESTRICT_ROOTING_LOG

static int sec_restrict_uid(void)
{
    int ret = 0;
    struct task_struct *parent_tsk;
    const struct cred *parent_cred;

    read_lock(&tasklist_lock);
    parent_tsk = current->parent;
    if (!parent_tsk) {
        read_unlock(&tasklist_lock);
        return 0;
    }

    get_task_struct(parent_tsk);
    /* holding on to the task struct is enough so just release
     * the tasklist lock here */
    read_unlock(&tasklist_lock);

    parent_cred = get_task_cred(parent_tsk);
    if (!parent_cred)
        goto out;
    if (parent_cred->euid == 0 || parent_tsk->pid == 1) {
        ret = 0;
    } else if (sec_check_execpath(current->mm, "/system/bin/pppd")) {
        PRINT_LOG("VPN allowed to use root permission");
        ret = 0;
    } else {
        PRINT_LOG("Restricted changing UID. PID = %d(%s) PPID = %d(%s)\n",
            current->pid, current->comm,
            parent_tsk->pid, parent_tsk->comm);
        ret = 1;
    }
    put_cred(parent_cred);
out:
    put_task_struct(parent_tsk);

    return ret;
}
#endif // End of CONFIG_SEC_RESTRICT_SETUID

[...]

SYSCALL_DEFINE3(setresuid, uid_t, ruid, uid_t, euid, uid_t, suid)
{
    const struct cred *old;
    struct cred *new;
    int retval;

#if defined CONFIG_SEC_RESTRICT_SETUID
    if(ruid == 0 || euid == 0 || suid == 0)
    {
        if(sec_restrict_uid())
            return -EACCES;
    }
#endif // End of CONFIG_SEC_RESTRICT_SETUID

If you could dump out dmesg, I'd expect to see "Restricted changing UID" messages, but that might not be possible if su is broken (chicken-and-egg).

Based on the code shown above, only one of the following conditions must be met in order to call setresuid() to set the real, effective, or saved UID to 0 (assuming you already have the right to do so under the standard Linux security model):

• The parent process must not exist, or its cred structure must be inaccessible
• The current process' executable name must match "/system/bin/pppd" (at least partially)
• The PPID must be 1 (init)
• The parent process' EUID must be 0

Meeting the latter condition probably involves the least disruption to the current code, so I've prototyped it in my branch. (Not tested on an actual Samsung device - does anyone want to give this a shot?)

Other options might include:

• Changing silent_run() to create an intermediate process with ppid 1 (e.g. via setsid())
• Changing silent_run() to create an intermediate process which exits prior to attempting setresuid()

[nfllab]

I confirm the dmesg message:
<3>[ 127.137573] Restricted changing UID. PID = 6922(su2) PPID = 6864(sh)

I can test if you provide a binary link or when I will have time to experiment with compiling.

[cernekee]

I can test if you provide a binary link or when I will have time to experiment with compiling.

Binaries for rev 699e4a9 of my tree:

https://dl.dropboxusercontent.com/u/169702767/su/su-binary-699e4a96.zip

[nfllab]

https://dl.dropboxusercontent.com/u/169702767/su/su-binary-699e4a96.zip

Works.

[ByteSecurity]

Thank you for all your answers,
I already get the solution in the link http://stackoverflow.com/questions/18226351/setuid-fails-with-permissiondenied-on-galaxy-s4
@cernekee analysis is very detail ,thanks 👍 :)

[vace117]

The new binaries worked for me as well.

Is there an official way to get this fix yet? The archive at http://download.clockworkmod.com/superuser/superuser.zip still does not include these changes, so I had to build my own zip file with the updated binaries in order to get this to work on Galaxy S4 (Canadian)

[koush]

Will do a rebuild.