On Sun, May 08, 2011 at 10:06:08PM +0200, Patrick Matth?i wrote: || Am 06.05.2011 15:10, schrieb Giuseppe Iuculano:
|| > On 05/04/2011 11:12 AM, Vincent Zweije wrote:
|| >> nobody@arrow:/$ ps axlO+T | grep ati[e]vnt
|| >> 0 0 32530 23664 20 0 3264 804 ? S ? 0:00
/bin/sh /etc/ati/authatieventsd.sh grant :0 /tmp/atievntX.aWEZgM
|| >> 4 1000 32548 32530 20 0 4296 628 ? S ? 0:00 su
vincent -c xauth -f /tmp/atievntX.aWEZgM add :0 .
76662e1da9b24d7ce5de363900837c18
|| >> 0 1000 32555 32548 20 0 2936 324 ? S ? 0:00
xauth -f /tmp/atievntX.aWEZgM add :0 . 76662e1da9b24d7ce5de363900837c18
|| >> nobody@arrow:/$
|| I am a bit limited in my time, but I tried to reproduce it with fglrx
|| 10-4 from unstable and kdm as login manager, but I were not suc.
|| * grepping for it => false
|| * logging in and then grepping for it => false
|| * after that shutting down kdm => false
Would that be 11-4, instead of 10-4?
I'd suspect that for some unknown reason, xauth process 32555 above
hangs, and that that is still there to see. Normally xauth is a short
lived process and it would not show up in a process listing unless you
timed it very precisely (which is, by the way, another mitigating factor
re security).
Looking at /etc/ati/authatieventsd.sh, this piece of code is wrong:
> case "$1" in
> grant)
> GetServerAuthFile $2 || exit -1
> DISP_AUTH_KEY=`xauth -f $SERVER_AUTH_FILE list | grep
> $DISP_SEARCH_STRING | awk '{ print $3 }'`
> if [ `pinky -fs | awk '{ if ($3 == "'$2'" || $(NF) == "'$2'" ) {
> print $1; exit; } }'` ]; then
> user=`pinky -fs | awk '{ if ($3 == "'$2'" || $(NF) == "'$2'" ) {
> print $1; exit; } }'`
> if [ -n "$DISP_AUTH_KEY" ]; then
> su $user -c "xauth -f $3 add $2 . $DISP_AUTH_KEY" ||
> exit -1
The $DISP_AUTH_KEY here puts the secret cookie on a command line. You just
should not do this. Write it to a temp file instead of catching it in the
DISP_AUTH_KEY variable, then have the su-xauth command read it from there.
Even better would be to use pipes only, but that may require quite a bit
of shell hackery if doable at all. For xauth scripting tasks it ought
to be possible though.
As a basic rule, catching the cookie in a variable is useless because
the only way to use it is to put it on the command line for others to see
(or export it to the environment, but that would be worse even.)
> else
> exit -1
> fi
> else
> if [ -n "$DISP_AUTH_KEY" ]; then
> xauth -f $3 add $2 . $DISP_AUTH_KEY || exit -1
Same here.
> else
> exit -1
> fi
> fi
> ;;
>
> revoke)
> if [ `pinky -fs | awk '{ if ($3 == "'$2'" || $(NF) == "'$2'" ) {
> print $1; exit; } }'` ]; then
> user=`pinky -fs | awk '{ if ($3 == "'$2'" || $(NF) == "'$2'" ) {
> print $1; exit; } }'`
> su $user -c "xauth -f $3 remove $2" || exit -1
> else
> xauth -f $3 remove $2 || exit -1
And strictly speaking, the same twice here, but the secret is being
removed so exploiting its knowledge would be very hard though not
theoretically impossible. Anyway, if your fixing the grant case, do the
revoke case at the same time so they use the same method. It's just good
software engineering.
> fi
> ;;
>
> *)
> exit -1
> ;;
> esac
> exit 0
|| Could you please retest it with 10-4? Did you installed the driver from
|| another location (amd website e.g.) before?
I have the following apt package sources:
$apt-cache policy fglrx-atieventsd
fglrx-atieventsd:
Installed: 1:11-3-1
Candidate: 1:11-3-1
Version table:
1:11-4-2 0
650 http://ftp.nl.debian.org/debian/ unstable/non-free i386 Packages
*** 1:11-3-1 0
700 http://ftp.nl.debian.org/debian/ testing/non-free i386 Packages
100 /var/lib/dpkg/status
1:10-9-3 0
600 http://ftp.nl.debian.org/debian/ stable/non-free i386 Packages
$
So, not installed from any other location.
--
Vincent Zweije <vinc...@zweije.nl> | "If you're flamed in a group you
<http://www.xs4all.nl/~zweije/> | don't read, does anybody get burnt?"
[Xhost should be taken out and shot] | -- Paul Tomblin on a.s.r.
signature.asc
Description: Digital signature
