Bug 76765 - sawfish can be used as a session killer
sawfish can be used as a session killer
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: sawfish (Show other bugs)
8.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Havoc Pennington
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-10-25 19:56 EDT by Michal Jaegermann
Modified: 2007-04-18 12:47 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-01-12 18:04:53 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Michal Jaegermann 2002-10-25 19:56:45 EDT
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 00:56:03 EDT
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 12:42:34 EDT
> 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 18:04:53 EST
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.