Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 76765 - sawfish can be used as a session killer
Summary: sawfish can be used as a session killer
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: sawfish
Version: 8.0
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Havoc Pennington
QA Contact: David Lawrence
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-10-25 23:56 UTC by Michal Jaegermann
Modified: 2007-04-18 16:47 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2003-01-12 23:04:53 UTC


Attachments (Terms of Use)

Description Michal Jaegermann 2002-10-25 23:56:45 UTC
Description of Problem:

Using sawfish-ui it is possible to lock the whole session in no time at
all leaving only remote access alive.  It is not necessary to play with
fonts at all (I know that this is totally broken) but scanning through
few themes seems to be enough.  I am afraid that I do not have a recipe
for that but few "natural" clicks here and there should to the job.

Apparently relevant pieces from strace look like this (3068 is the main
process of sawfish, 3121 is its forked child)
........
3121  execve("/bin/tar", ["tar", "--version"], [/* 34 vars */]) = 0
3121  uname({sys="Linux", node="smok.home.front", ...}) = 0
3121  brk(0)                            = 0x806dd50
3121  open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory)
3121  open("/etc/ld.so.cache", O_RDONLY) = 3
3121  fstat64(3, {st_mode=S_IFREG|0644, st_size=111640, ...}) = 0
3121  old_mmap(NULL, 111640, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40013000
3121  close(3)                          = 0
3121  open("/lib/i686/libc.so.6", O_RDONLY) = 3
......
3121  open("/usr/share/locale/en_CA.UTF-8/LC_MESSAGES/tar.mo", O_RDONLY) = -1
ENOENT (No such file or directory)
3121  open("/usr/share/locale/en_CA.utf8/LC_MESSAGES/tar.mo", O_RDONLY) = -1
ENOENT (No such file or directory)
3121  open("/usr/share/locale/en_CA/LC_MESSAGES/tar.mo", O_RDONLY) = -1 ENOENT
(No such file or directory)
3121  open("/usr/share/locale/en.UTF-8/LC_MESSAGES/tar.mo", O_RDONLY) = -1
ENOENT (No such file or directory)
3121  open("/usr/share/locale/en.utf8/LC_MESSAGES/tar.mo", O_RDONLY) = -1 ENOENT
(No such file or directory)
3121  open("/usr/share/locale/en/LC_MESSAGES/tar.mo", O_RDONLY) = -1 ENOENT (No
such file or directory)
3121  write(1, "tar (GNU tar) 1.13.25\nCopyright "..., 297) = 297
3068  <... select resumed> )            = 1 (in [11], left {0, 994077})
3121  munmap(0x40013000, 4096 <unfinished ...>
3068  rt_sigaction(SIGCHLD, NULL,  <unfinished ...>
3121  <... munmap resumed> )            = 0
3068  <... rt_sigaction resumed> {0x40055ca0, [CHLD], SA_RESTORER, 0x42028c48},
8) = 0
3121  _exit(0)                          = ?
3068  rt_sigaction(SIGCHLD, {0x40055ca0, [CHLD], SA_RESTORER|SA_RESTART,
0x42028c48}, NULL, 8) = 0
3068  read(11, "tar (GNU tar) 1.13.25\nCopyright "..., 1024) = 297
3068  rt_sigaction(SIGCHLD, NULL, {0x40055ca0, [CHLD], SA_RESTORER|SA_RESTART,
0x42028c48}, 8) = 0
3068  rt_sigaction(SIGCHLD, {0x40055ca0, [CHLD], SA_RESTORER, 0x42028c48}, NULL,
8) = 0
3068  select(1024, [11 14], NULL, NULL, {1, 0}) = 2 (in [11 14], left {1, 0})
3068  rt_sigaction(SIGCHLD, NULL, {0x40055ca0, [CHLD], SA_RESTORER, 0x42028c48},
8) = 0
3068  rt_sigaction(SIGCHLD, {0x40055ca0, [CHLD], SA_RESTORER|SA_RESTART,
0x42028c48}, NULL, 8) = 0
3068  read(11, "", 1024)                = 0
3068  read(14, "", 1024)                = 0
3068  wait4(3121,  <unfinished ...>
........

(and we are hanging here until the whole session is killed after logging
overa network; sometimes things refuse to go away until reboot).

I am not sure if this is really sawfish.  The whole gnome-session
setup seems to be currently so delicate that looking at it a wrong way
is messing it up.  The trace above suggests that locale stuff may be
responsible.

Comment 1 Havoc Pennington 2002-10-26 04:56:03 UTC
Perhaps a stuck server grab; if you kill sawfish or sawfish-ui, do things unfreeze?

I don't understand the strace though. The tar process has exited, 
and then wait4() is called for the tar process, so wait4() should return
immediately (I double-checked in the main page).

Comment 2 Michal Jaegermann 2002-10-26 16:42:34 UTC
> Perhaps a stuck server grab; if you kill sawfish or sawfish-ui, do things
> unfreeze?

That would be the first thing to try, wouldn't it?  Unfortunately the answer
is no.  On one try I managed to get things back with 'killall gdm-binary'.
More "delicate" attempts did not have any visible effect.
On the other one things get so knotted that none of signals to any of
session processes worked.  It was kind of a strange as 'ps' did not show
up any of these in "D" state but they were mostly (all?) "S".  Still multiple
attempts to kill with various signals were ineffective.  Eventually I rebooted.
Maybe 'telinit 1' would work too but I did not try.  An error in a hindsight.

> I don't understand the strace though.
That makes two of us. :-)  I was scratching my head about that as well.
I hoped that you may know much more about possible internal interactions.

Comment 3 Havoc Pennington 2003-01-12 23:04:53 UTC
I don't foresee being able to make progress on this.
If we could come up with a smaller test case maybe the kernel guys
could look at it.


Note You need to log in before you can comment on or make changes to this bug.