exec() with pmset

  • Hi,
    I am really not sure which list to post this to, but this list always seems
    to help.

    For some reason i can not make pmset work in my "authtool" which has a
    setuid to have root privs,

    case kMyAuthorizedHibernateNormal: {

    /* Split the proc into parent/child. */

    pid = fork();

    /* Child code. */

    if(pid == 0) {

    fprintf(stderr, "HIBNOR\n");

    execl("/usr/bin/pmset", "-a hibernatemode 3", NULL);

    }

    /* Parent code. */

    else {

    wait(&status);

    fprintf(stderr, "HIBNOR : %d\n", status);

    }

    result = status;

    break;

    }

    The code has to be forked and execl as system() will lose the root privs,
    running that code however returns 13 or 256 (is there a way to know what
    these values are?)
  • On 31 Oct 07, at 20:15, Andrew James wrote:
    > I am really not sure which list to post this to, but this list
    > always seems
    > to help.
    >
    > For some reason i can not make pmset work in my "authtool" which has a
    > setuid to have root privs,
    <snip>
    > The code has to be forked and execl as system() will lose the root
    > privs,
    > running that code however returns 13 or 256 (is there a way to know
    > what
    > these values are?

    The main issue I see with your code right now is that you're misusing
    execl(). The line

    execl("/usr/bin/pmset", "-a hibernatemode 3", NULL);

    is incorrect - you must specify arguments to the child individually,
    as well as including its argv[0]. Read 'man execl' for more details.

    The libc call perror() will print a human-readable version of errors.
    Error 13 is "permission denied" (EACCES). 256 isn't a valid error
    code, but it is a plausible return value from wait() indicating that
    the child process exited with status 1 (which pmset is expected to do
    in this situation).

    Incidentally, keep in mind that execl() may return if it fails. You
    should generally follow it up with an exit() to avoid returning to
    your main program, as the behavior of AppKit in such situations is
    undefined.
  • On 10/31/07, Andrew James <semaja2...> wrote:
    > Hi,
    > I am really not sure which list to post this to, but this list always seems
    > to help.
    >
    > For some reason i can not make pmset work in my "authtool" which has a
    > setuid to have root privs,

    Beyond your problems with execl, here are a couple ideas (good for at
    least 10.4... don't know about 10.5):

    a) Make sure you read and understand
    <http://developer.apple.com/documentation/Security/Conceptual/authorization_
    concepts/03authtasks/chapter_3_section_3.html#//apple_ref/doc/uid/TP3000099
    5-CH206-BCIGAIAG
    >

    b) Are you using AuthorizationExecuteWithPrivileges to launch your
    executable? GO BACK TO (a), you're doing it wrong.
    AuthorizationExecuteWithPrivileges is good for one thing only, and
    that's to fix the set-uid-bit on the file.

    c) Now that you understand everything, take a look at MoreIsBetter,
    particularly MoreSecurity
    <http://developer.apple.com/samplecode/MoreIsBetter/listing193.html>.
    It's a library to help you write secure and well behaved helper apps.
    Hint: you don't need to get all of MoreIsBetter to compile. Just
    import MoreSecurity, MoreUNIX, and MoreCFQ (I usually have them in a
    separate target, as a static library).

    d) Your original problem (beyond execl) could be that you need to call
    seteuid( 0 ). If you're using MoreSecurity, this is wrapped up in
    MoreSecSetPrivilegedEUID().
  • On 1.11.2007, at 5:29, stephen joseph butler wrote:

    > On 10/31/07, Andrew James <semaja2...> wrote:
    >> Hi,
    >> I am really not sure which list to post this to, but this list
    >> always seems
    >> to help.
    >>
    >> For some reason i can not make pmset work in my "authtool" which
    >> has a
    >> setuid to have root privs,
    >

    I could not find any documentation on this (not that I tried very
    hard), but it seems that in Leopard a child process system()'d by a
    root setuid process does not inherit uid/euid. I.e. you can only do
    superhuman evil things in your code, but any process started by your
    code will fall back to mere mortal privileges.

    I did not try directly exec()-ing, but I guess it is the same, as
    system() is just a wrapper for lazy people like me :-)

    At least this is the way it worked with my moresecurity-inspired tool...

    izidor
  • On 01/11/2007, Andrew James <semaja2...> wrote:

    > The code has to be forked and execl as system() will lose the root privs,
    > running that code however returns 13 or 256 (is there a way to know what
    > these values are?)

    can you not use popen() instead?

    --
    Igor :-)
  • On 1.11.2007, at 13:26, Izidor Jerebic wrote:
    >
    >> On 10/31/07, Andrew James <semaja2...> wrote:
    >>>
    >>> For some reason i can not make pmset work in my "authtool" which
    >>> has a
    >>> setuid to have root privs,
    >>
    >
    > I could not find any documentation on this (not that I tried very
    > hard), but it seems that in Leopard a child process system()'d by a
    > root setuid process does not inherit uid/euid. I.e. you can only do
    > superhuman evil things in your code, but any process started by your
    > code will fall back to mere mortal privileges.
    >
    > I did not try directly exec()-ing, but I guess it is the same, as
    > system() is just a wrapper for lazy people like me :-)
    >
    > At least this is the way it worked with my moresecurity-inspired
    > tool...

    I should think/test before I post. Fork/exec keeps the setuid just
    fine, it's system() that doesn't.

    As for the status (straight from sys/wait.h) - it is 8 bit shifted
    exit() value from child together with signal status, so 256 means
    child did exit(1), and 13 means there was signal regarding pipes
    (SIGPIPE).

    Definitely the parameters for execl() as typed in your email are
    wrong, so that may be a problem.
    Another possibility is that maybe pmset has become hostile towards
    running as setuid...

    izidor
previous month november 2007 next month
MTWTFSS
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30    
Go to today