You are not logged in.
For the solution see this post.
If you do not want to have unpackaged and unmaintained scripts on your system if you can avoid it, check out sux, and see this post.
#######################################
Hello everybody,
let's say I am in an X session with my regular user "myuser", and I want to run a GUI application "guiapp" using some different user, let's call it "guiappuser".
This is due to safety reasons, so that guiapp can't access the files of myuser.
For the sake of testing this, the application is pluma, the text editor of the MATE desktop environment.
Now, this sort of works, as long guiappuser has a valid password set:
gksu -u guiappuser plumaHowever it prompts me for guiappuser's password. I do not want guiappuser to have a password, there will be more users of this kind for other applications, and it would be a hassle managing all their passwords. Besides, other people that happen to use the myuser session should be able to launch those programs in their respective restricted users, too, and they would not know about any passwords.
I did some research and found out that sudo can be configured in a way to let e.g. myuser run arbitrary programs as guiappuser without prompting for either user's password. To this end I have this line in my sudoers file:
myuser ALL=(guiappuser) NOPASSWD: ALLThis works flawlessly for command line applications, for example "id":
[myuser@myhost ~]$ sudo -u guiappuser id
uid=1003(guiappuser) gid=1003(guiappuser) groups=1003(guiappuser),1106(some_other_group)But the analogous gksudo call fails miserably for GUI applications, such as pluma. Here with --debug:
[myuser@myhost ~]$ gksudo -u guiappuser --debug pluma
No ask_pass set, using default!
xauth: /tmp/libgksu-gA4rsK/.Xauthority
STARTUP_ID: gksudo/pluma/5275-0-myhost_TIME0
cmd[0]: /usr/bin/sudo
cmd[1]: -H
cmd[2]: -S
cmd[3]: -p
cmd[4]: GNOME_SUDO_PASS
cmd[5]: -u
cmd[6]: guiappuser
cmd[7]: --
cmd[8]: pluma
buffer: -No protocol specified-
buffer: --
buffer: --
buffer: -(pluma:5277): Gtk-WARNING **: cannot open display: :0.0-
buffer: --
buffer: --
(many more such lines)
buffer: --
buffer: --
brute force GNOME_SUDO_PASS ended...
No password prompt found; we'll assume we don't need a password.
Calling pass_not_needed window...
xauth: /tmp/libgksu-gA4rsK/.Xauthority
xauth_env: /home/myuser/.Xauthority
dir: /tmp/libgksu-gA4rsKIn /etc/sudoers there is a section where it says:
## Run X applications through sudo; HOME is used to find the
## .Xauthority file. Note that other programs use HOME to find
## configuration files and this may lead to privilege escalation!
# Defaults env_keep += "HOME"But even if I uncomment this line it makes no difference at all.
Has anyone managed to make gksudo work on Arch for a "regular" user, i.e. not just launching stuff as "root"?
Last edited by eomanis (2014-08-09 19:18:58)
Offline
http://serverfault.com/questions/51005/ … r-on-linux
Make sure to read the entire discussion. There are multiple approaches.
EDIT: I am puzzled, why you would need gksudo, if you don't want it to display a password query anyway. The default sudoers allows Xauthority passthrough, so you should be able to run "sudo Xapplication". All you need to do is make sure the second user knows about the xauth magic cookie. Well, look at the link I gave you.
EDIT: Sorry for being cryptic. You can pass the xauth magic cookie from a user to root but obviously not from a user to another user using sudo.
Last edited by Awebb (2014-08-07 09:14:15)
Offline
Hey, thank you a lot Awebb, with your information I was able to come up with a solution.
I ended up writing some bash programs that use sudo -u <user> to run a graphical application and pass the xauth authorization information to the desired user.
There are 2 parts, the first part runs as "myuser", and a second part that is run as "guiappuser" using sudo -u, if we keep the terms of my first example.
For the time being I put them into /usr/local/bin.
1st part: xsudo (this is the program that you call)
#!/bin/bash
set -o pipefail
# The name of the companion launcher program that is run as the target
# user
var_launchername="$(basename "$0")"_launcher
if [ $# -lt 2 ]; then
# Not enough arguments given, or e.g. --help as single argument
echo "This program runs a graphical program as a different user using"
echo "sudo -u targetuser program [argument]..."
echo "and a few tweaks."
echo ""
echo "Usage:"
echo "<program invocation> targetUser program [argument]..."
exit 1
fi
# Determine the directory this script file is located in
var_scriptdir="$(dirname "$0")"
var_launcher="$var_scriptdir"/"$var_launchername"
# Ensure that the companion launcher program exists
if ! type "$var_launcher" &> /dev/null; then
echo "ERROR: The companion launcher program \"$var_launcher\" does not exist or is not accessible or not executable" >&2
exit 1
fi
# Parse the arguments
var_user="$1"
shift 1
# Extract the xauth list line that has the correct host name and
# display:
# myhost/unix:0 MIT-MAGIC-COOKIE-1 11b76a913dc13d9a64473a9d677ca3c2
# ^^^^^^ ^^
# hostname display
# Sometimes, DISPLAY is set to something like ":0.0", even though the
# xauth line looks like the one above.
# In such a case, keep ":0" but cut off the ".0".
var_display="$(echo -n "$DISPLAY" | sed -re 's/^(:[0-9]+)\.[0-9]*$/\1/')"
if ! var_xauthline="$(xauth list | grep "^$(hostname)" | grep "$var_display MIT-MAGIC-COOKIE-1 ")" \
|| [ "" == "$var_xauthline" ] || [ $(echo "$var_xauthline" | wc -l) -gt 1 ]; then
echo "ERROR: Unable to obtain the correct output text line from xauth list" >&2
exit 1
fi
# Extract the hex key from the xauth list line:
# myhost/unix:0 MIT-MAGIC-COOKIE-1 11b76a913dc13d9a64473a9d677ca3c2
# ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
# hexkey
if ! var_hexkey="$(echo -n "$var_xauthline" | sed -re 's/^.+ ([^ ]+)$/\1/')" \
|| [ "" == "$var_hexkey" ] || [ ${#var_hexkey} -ne 32 ]; then
echo "ERROR: Unable to extract the hex key from the xauth output text line \"$var_xauthline\"" >&2
exit 1
fi
# Showtime
# DISPLAY and the xauth hex key are piped into the launcher and NOT
# supplied as arguments, because if they were arguments they would show
# up in process listings, and any user could read them from there
echo -n "$var_display"$'\n'"$var_hexkey"$'\n' | sudo -u "$var_user" -- "$var_launcher" "$@"2nd part: xsudo_launcher (this part adds the xauth authorization entry and finally runs the desired program)
#!/bin/bash
set -o pipefail
# Where the .Xauthority file should be put
XAUTHORITY=~/.Xauthority
if [ $# -lt 1 ]; then
# Not enough arguments given
# TODO Better documentation
"Usage:"
"<program invocation> program [argument]... < display<LF>xauthHexKey<LF>"
exit 1
fi
# Read the secret stuff from STDIN. Data expected:
# DISPLAY<LF>
# authHexKey<LF>
DISPLAY=""
var_hexkey=""
declare -i var_index
var_index=0
while read -srd $'\n' -n 120 var_data; do
if [ 0 == $var_index ]; then
DISPLAY="$var_data"
elif [ 1 == $var_index ]; then
var_hexkey="$var_data"
fi
if [ $var_index -ge 1 ]; then
# Only read the lines 0 and 1.
# If this is line 1 or greater, leave the read loop before
# its next iteration.
break
fi
((++var_index))
done
if [ "" == "$DISPLAY" ] || [ "" == "$var_hexkey" ]; then
echo "ERROR: Data for display and xauthHexKey not given via STDIN" >&2
exit 1
fi
# Ensure that the .Xauthority file exists. If it does not exist, create
# it.
# This is apparently necessary for xauth add to work.
[ -f "$XAUTHORITY" ] || touch "$XAUTHORITY"
# Export the DISPLAY and XAUTHORITY variables
export DISPLAY
export XAUTHORITY
# Add the display and hex key to the .Xauthority file using xauth
#
# TODO Prevent old authorization entries from accumulating in the
# .Xauthority file
xauth add "$DISPLAY" "MIT-MAGIC-COOKIE-1" "$var_hexkey"
# Run the program and its arguments
"$@"eomanis
Last edited by eomanis (2014-08-09 20:36:18)
Offline
That's great! Is there a reason besides education and a good time coding that stopped you from using sux?
Offline
Ah, you got me. Basically I did not use sux because pacman didn't have it, and I forgot to look in the AUR.
Well, now that I found sux there I might give it a go. Yet as far as I can tell it does not use sudo, only su. And su wants passwords if I am not mistaken (tell me if I am wrong on that one, please).
Anyway, I might use sux as a starting point to get a PKGBUILD done so that I don't have non-packaged software lying around on my system.
eomanis
Offline
sux uses su, but you can work around that easily by specifying commands in the sudoers, not just the base executable, e.g. /usr/bin/sux guiuser firefox, instead of just /usr/bin/sux and call it with sudo sux guiuser firefox.
However, I salute your efforts! You are right, why use a program, that does what a little script can do?
Offline