Best way elevate the privileges programmatically under different versions of Linux?

There is a standard way (working across Linux distributions) to launch a process (from another application) asking for the root password in order to elevate privileges?

I tried to use gksudo (it is installed in ubuntu by default), but under other distributions (or under other desktop manager) it may not be installed.

From stackoverflow

• That works everywhere but does not cache the password and asks for the root and not the user password (as sudo does):

  su - -c command
  

  EDIT: Not on ubuntu where the root-account is disabled. Probably you need something like that:

  test -x /usr/bin/sudo && sudo command || su - -c command
  

  vartec : su - asks for root password and allows you to do anything, while sudo may be configured to ask user password and limit commands you're allowed to execute.

  R. Bemrose : @vartec: The original question includes the text "asking for the root password in order to elevate privileges" which is precisely what su does.

  ephemient : Will not work on distributions like Ubuntu, where root is not permitted to log in interactively.

  Johannes Weiß : ephemient, oh, your right!

• The only default thing is text mode su. Most distros have also sudo installed.

  Now, in KDE based distros you'll have kdesu, while in GNOME based it'll be gksu and gksudo. Machines in Kerberized domains have ksu.

  You might try to use /etc/sysconfig/desktop to see which is the default desktop.

• I would recommend looking at PolicyKit which is what most modern distros are using to accomplish this.

• Traditionally, if your application needs to allow a user to elevate privileges, it installs its own single-purpose setuid executable -- single-purpose meaning that it performs the task needed, instead of acting as a general-purpose launcher.

  $ su -
  # cp `type -p id` /usr/local/bin/root-id
  # chown root:users /usr/local/bin/root-id
  # chmod 4750 /usr/local/bin/root-id
  $ /usr/local/bin/root-id
  ... euid=0(root) ...
  

  OTOH setuid executables have also been a common source of security holes too, so exercise care.