Subject: Re: FvwmCommandS on Linux

From: Chris Rankin <[email-masked]>
Date: Tue, 13 Jun 2000 00:28:40 +1000 (EST)

Well the latest fix doesn't seem to have any effect for me either. I'm
> still seeing multiple hits on the condition if (len == 0) per
> second.  If I remove my print from there I notice I hit the continue at
> process_message every time I change focus.

The only (len == 0) that I can see is line 280 of FvwmCommandS.c; if
this read is returning 0 bytes then the remote end of the pipe must
have been closed. This would explain why you are getting a tight loop,
since this descriptor will now *always* appear readable until it is
closed. Therefore the question becomes "why has someone closed the
remote end of the pipe?".

I have modified the handling so that FvwmCommandS quits in this
instance (that'll fix your tight loop >;) !!) Maybe you can describe
exactly what you're doing to produce this bug?

Chris.
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Brad Giaccio <[email-masked]>
Date: Mon, 12 Jun 2000 11:01:21 -0400

> exactly what you're doing to produce this bug?

 you are correct that took care of my loop and FvwmCommandS now exits
 with the message "FvwmCommandS server error in reading fifo, No such
 file or directory".  The problem is when I was in the tight loop,
 I could actually use FvwmCommand to issue some fvwm function.  So
 wouldn't that imply that the remote end hadn't closed its pipe?

As for what I'm doing 

install Redhat 6.2
download cvs tree of fvwm
automake --add-missing
autoreconf
./configure  \
--prefix=/home/bgiaccio/fvwm23 \
--exec-prefix=/home/bgiaccio/fvwm23/`uname -s` \
--with-gtk-prefix=`gtk-config --prefix` \
--with-gnome-prefix=`gnome-config --prefix` \
--with-imlib-prefix=`imlib-config --prefix` \
--enable-gnome
make
make install

have an rc with FvwmCommandS in the init function.

Thats all I'm doing.

-- 
--- There are two kinds of knowledge, you either know the answer or
			you know where to find it
		      -Kane, Johnson, and anonymous
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Chris Rankin <[email-masked]>
Date: Tue, 13 Jun 2000 08:27:54 +1000 (EST)

> have an rc with FvwmCommandS in the init function.

Odd. I launched FvwmCommandS successfully; I am using Linux 2.2.16
(don't know if that makes a difference). The sequence of events here
is therefore:

- FvwmCommandS launches
- it notices that the command FIFO is readable
- it tries to read zero bytes (EOF indicator)
- LOOP!

The FIFOs that were created on my system looked like this:

   0 prw-------    1 chris    users           0 Jun 13 07:52 /home/chris/.FvwmCommand-wellhouse:0.0C
   0 prw-------    1 chris    users         440 Jun 13 07:52 /home/chris/.FvwmCommand-wellhouse:0.0M

and disappeared as soon as FvwmCommandS died. Can you check whether
your FIFOs look anything like this? (a bit of debug hacking will
probably be required...)

Chris

---

From: Brad Giaccio <[email-masked]>
Date: Tue, 13 Jun 2000 09:22:07 -0400

> your FIFOs look anything like this? (a bit of debug hacking will

my pipes look like 
-rw-------    1 bgiaccio users           0 Jun 13 09:09 /home/bgiaccio/.FvwmCommand-leila:0.0C
-rw-------    1 bgiaccio users           0 Jun 13 09:09 /home/bgiaccio/.FvwmCommand-leila:0.0M

my kernel is 2.2.14-6.1.1smp

my experience is the same I can get it started but every time it does
the select it notices that the FIFO is readable and then reads zero
bytes, which is why I get the tight loop.  I'm willing to except that it
is a kernel problem and upgrade if necessary I just can't believe that
it is.

My question is does FvwmCommandS just function or does it behave
properlly for you? From the above I'm not sure.

Brad

---

From: Tim Phipps <[email-masked]>
Date: Tue, 13 Jun 2000 14:38:43 +0100

> is a kernel problem and upgrade if necessary I just can't believe that

This whole thing seemed to start after I changed FvwmCommandS to prevent
some delays I get. Does the older version (cvs version 1.20) work OK for
you?

If it does I think it best to just revert to the older one and I'll
suffer the delays.
Cheers,
Tim.

---

From: Chris Rankin <[email-masked]>
Date: Tue, 13 Jun 2000 23:51:25 +1000 (EST)

> properlly for you? From the above I'm not sure.

Yes, it does (I think). No tight loop. My analysis was purely
theoretical. Your FIFOs don't have the "p", BTW. Is that a copy-error?

Chris

---

From: Chris Rankin <[email-masked]>
Date: Wed, 14 Jun 2000 00:01:20 +1000 (EST)

> If it does I think it best to just revert to the older one and I'll

The FvwmCommandS as-is *looks* OK; I think it's too early to throw in
the towel at the moment because there must be something deeper going
on.

Chris.

---

From: Brad Giaccio <[email-masked]>
Date: Tue, 13 Jun 2000 10:12:40 -0400

> theoretical. Your FIFOs don't have the "p", BTW. Is that a copy-error?

I noticed the lack of p as well, and am at a loss to explain it.  I
see an s for the socket created by FvwmConsole but I can't think of
something else using pipes to verify at the moment.

Brad

---

From: Chris Rankin <[email-masked]>
Date: Wed, 14 Jun 2000 00:20:47 +1000 (EST)

> -rw-------    1 bgiaccio users           0 Jun 13 09:09 /home/bgiaccio/.FvwmCommand-leila:0.0M

This could be the problem ... (or maybe not). "p" is the FIFO
indicator; pipes exist purely in kernel memory I think. Do these
"things" disappear when FvwmCommandS dies? If they don't then try
deleting them and restart FvwmComamndS. What type of filesystem is
your $HOME directory on? And what does a FIFO created using

$ mkfifo named-pipe

look like?

Chris

---

From: Brad Giaccio <[email-masked]>
Date: Tue, 13 Jun 2000 10:22:38 -0400

I had kind of hoped you were right Tim, but I tried revision 1.20 and
1.19 under Linux with no luck, I know that 1.19 worked for me on solaris
as did 1.20, so your delay stuff is not the culprit.

On Tue, Jun 13, 2000 at 02:38:43PM +0100, Tim Phipps wrote:

> Brad Giaccio wrote:
>
> > my experience is the same I can get it started but every time it
> > does the select it notices that the FIFO is readable and then reads
> > zero bytes, which is why I get the tight loop.  I'm willing to
> > except that it is a kernel problem and upgrade if necessary I just
> > can't believe that it is.
>
> This whole thing seemed to start after I changed FvwmCommandS to
> prevent some delays I get. Does the older version (cvs version 1.20)
> work OK for you?
>
> suffer the delays.  Cheers, Tim.

---

From: Brad Giaccio <[email-masked]>
Date: Tue, 13 Jun 2000 10:34:50 -0400

> your $HOME directory on? And what does a FIFO created using

ls -l /tmp/FvwmCommand-leila:0.0* 
prw-------    1 bgiaccio users           0 Jun 13 10:27 /tmp/FvwmCommand-leila:0.0C
prw-------    1 bgiaccio users          39 Jun 13 10:24 /tmp/FvwmCommand-leila:0.0M

Well Chris, I believe you deserve a kiss, but since I'm a married man,
and just not that kind of guy you'll have to find someone else to do it.

As soon as you asked me the filesystem the light when off in my head.  I've been having all sorts of troulble with NFS on linux, linux supports nfs 3 whil solaris 2.5 and 2.6 are nfs 2.0.  So now I have to lessons learned about nfs.

1.) Don't compile c/c++ on an nfs mounted filesystem when client v3 and server is v2
2.) Don't create pipes in the same situation

So the good news is it is a stupid NFS problem so starting FvwmCommandS and pointting it to /tmp instead of $HOME works for me.  So now the question is with the changes just made should we pack out some of them.

Thanks,
Brad

---

From: Dan Espen <[email-masked]>
Date: Tue, 13 Jun 2000 10:53:44 -0400

Brad Giaccio <[email-masked]> writes:
> As soon as you asked me the filesystem the light when off in my head.  I've b
> een having all sorts of troulble with NFS on linux, linux supports nfs 3 whil
>  solaris 2.5 and 2.6 are nfs 2.0.  So now I have to lessons learned about nfs
> .
> 
> So the good news is it is a stupid NFS problem so starting FvwmCommandS and p
> ointting it to /tmp instead of $HOME works for me.  So now the question is wi
> th the changes just made should we pack out some of them.

Since FvwmCommandS is already doing an fstat, it might be a good idea
for it to check st_mode for S_IFIFO.  That might have caught this.

I would have guessed that the mkfifo call would have returned an error.
I guess not.

--
Dan Espen
444 Hoes Lane  Room RRC 1C-214           E-mail: [email-masked]
Piscataway, NJ 08854                     Phone: (732) 699-5570
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: [email-masked] (Paul D. Smith)
Date: 13 Jun 2000 11:34:45 -0400

%% Dan Espen <[email-masked]> writes:

  >> So the good news is it is a stupid NFS problem so starting
  >> FvwmCommandS and p ointting it to /tmp instead of $HOME works for
  >> me.

  de> Since FvwmCommandS is already doing an fstat, it might be a good
  de> idea for it to check st_mode for S_IFIFO.  That might have caught
  de> this.

  de> I would have guessed that the mkfifo call would have returned an
  de> error.  I guess not.

I think it's generally not a good idea to create named pipes like this
in the user's home directory.  Home directories are quite often on
shared media like NFS filesystems.

Typically things like this go in /var/tmp or /var/run or someplace
similar.  /var/tmp is probably the most common, followed by /tmp
itself.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <[email-masked]>         Network Management Development
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
   These are my opinions---Nortel Networks takes no responsibility for them.
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Tim Phipps <[email-masked]>
Date: Tue, 13 Jun 2000 17:20:43 +0100

> So the good news is it is a stupid NFS problem so starting FvwmCommandS and pointting it to /tmp instead of $HOME works for me.  So now the question is with the changes just made should we pack out…

I think all of Chris' changes are good, I've left a printf in there and
some code will probably never get executed.  Now that the names of the
pipes have $DISPLAY in them we could just make them appear in /tmp or
/var/tmp. Which one is more portable?

Cheers,
Tim.

---

From: Dan Espen <[email-masked]>
Date: Tue, 13 Jun 2000 12:49:12 -0400

Tim Phipps <[email-masked]> writes:
> Brad Giaccio wrote:
> > So the good news is it is a stupid NFS problem so starting FvwmCommandS and
>  pointting it to /tmp instead of $HOME works for me.  So now the question is 
> with the changes just made should we pack out some of them.
> 

Solaris seems to like to use /tmp:

fork> /bin/ls -l /tmp/.*/* | grep '^p'
prw-rw-rw-   1 root     root           0 May 31 09:09 /tmp/.pcmcia/pcram
prw-rw-rw-   1 dane     root           0 May 31 09:10 /tmp/.X11-pipe/X0
prw-------   1 root     root           0 Jun 13 06:18 initpipe
prw-------   1 root     root           0 Jun 13 06:18 utmppipe

Nothing in /var/tmp

---

From: Chris Rankin <[email-masked]>
Date: Wed, 14 Jun 2000 07:54:26 +1000 (EST)

> similar.  /var/tmp is probably the most common, followed by /tmp

Moving these pipes into /tmp or /var/tmp is fine, but don't forget
that more than one user might want to run fvwm2 on the same
system. We'll have to put the uid into the pipe name somehow.

Chris

---

From: Alex Belits <[email-masked]>
Date: Tue, 13 Jun 2000 15:12:02 -0700 (PDT)

> system. We'll have to put the uid into the pipe name somehow.

  Won't something under home directory be good enough? Not to mention
various exploitable race conditions that plague things that use /tmp-based
directories.

-- 
Alex

---

From: Chris Rankin <[email-masked]>
Date: Wed, 14 Jun 2000 08:16:42 +1000 (EST)

> We'll have to put the uid into the pipe name somehow.

DOH! The user might have multiple X sessions, so the uid is no good
either. We'll have to use each FvwmCommandS' PID.

Chris

---

From: [email-masked] (Paul D. Smith)
Date: 13 Jun 2000 18:19:09 -0400

>> We'll have to put the uid into the pipe name somehow.

  cr> DOH! The user might have multiple X sessions, so the uid is no
  cr> good either. We'll have to use each FvwmCommandS' PID.

The display is already there; isn't that enough?

I guess the user could be running more than one FvwmCommandS at the same
time?  Seems confusing tho...

---

From: [email-masked] (Paul D. Smith)
Date: 13 Jun 2000 18:21:20 -0400

%% Alex Belits <[email-masked]> writes:

  ab> On Wed, 14 Jun 2000, Chris Rankin wrote:

  >> > Typically things like this go in /var/tmp or /var/run or
  >> someplace > similar.  /var/tmp is probably the most common,
  >> followed by /tmp > itself.

  >> system. We'll have to put the uid into the pipe name somehow.

  ab> Won't something under home directory be good enough? Not to
  ab> mention various exploitable race conditions that plague things
  ab> that use /tmp-based directories.

You missed the context; currently we use the home directory, but often
a user's home directory is on an NFS filesystem or similar, where you
often can't create named pipes.

It's important to have the pipe created on a local filesystem.  I
personally vote for /var/tmp first, since /tmp is sometimes a ramdisk
(although you can create pipes on that) or sometimes even remote-mounted
itself (bogus, but I've seen it when people keep running out of /tmp
space).

If /var/tmp isn't there, /tmp is a good fallback.

BTW, on my Solaris system apps seem to be split 50/50 whether they use
/tmp or /var/tmp.  I have pipes, etc. in both.

---

From: Chris Rankin <[email-masked]>
Date: Wed, 14 Jun 2000 08:28:20 +1000 (EST)

> The display is already there; isn't that enough?

To be honest, I don't think I've seen a lot of boxes hosting multiple
X sessions so I'm a bit fuzzy on the numbering scheme. I'll take your
word for it :-)

> time?  Seems confusing tho...

If it can be done, then someone *will* do it. I learnt that lesson the
hard way.

Chris

---

From: Chris Rankin <[email-masked]>
Date: Wed, 14 Jun 2000 08:22:09 +1000 (EST)

> Not to mention various exploitable race conditions that plague
> things that use /tmp-based directories.

Exploitable? I hope not, but since the FIFO will be owned by the user
and not by root then hopefully s/he will only be able to exploit
her/himself (unless I'm missing something here).

Chris

---

From: Alex Belits <[email-masked]>
Date: Tue, 13 Jun 2000 16:02:56 -0700 (PDT)

> her/himself (unless I'm missing something here).

  While pipe exists, yes. Problems start when it is being created or
deleted -- for example, what should it do if the pipe with exactly the
same name, writable for everyone (or owned by some other user) exists?
What if there is a file with that name?

-- 
Alex

----------------------------------------------------------------------
 Excellent.. now give users the option to cut your hair you hippie!
                                                  -- Anonymous Coward

---

From: Chris Rankin <[email-masked]>
Date: Wed, 14 Jun 2000 19:25:27 +1000 (EST)

> What if there is a file with that name?

Well part of the original problem was that the FIFO was being created
*not* as a FIFO (-rw-------) and so putting FvwmCommandS into a tight
loop when it all went horribly wrong. Somebody has proposed checking
the FIFO using stat() and ensuring that it statisfies S_ISFIFO(). We
can also check the st_uid and st_mode fields at this point, and I
imagine that we will exit if there is anything wrong. We could even
use lstat() instead of stat() to spot people putting soft links in
/tmp pointing to goodness-knows-where, although if we can guarantee
that the mode is 0600 and the UID is correct then maybe this isn't
such a big deal.

Chris

---

From: Tim Phipps <[email-masked]>
Date: Wed, 14 Jun 2000 13:52:55 +0100

> that the mode is 0600 and the UID is correct then maybe this isn't

How's this for a plan:

FvwmCommandS tries the following in /var/tmp and /tmp:
*) If the pipes already exist kill off any running FvwmCommandS and
remove them. (this happens already)
*) Create new pipes.
*) Open the pipes, stat them and check for S_ISFIFO and correct mode.

FvwmCommand will look in /var/tmp and then /tmp before failing.

Should I do this?

Cheers,
Tim.

---

From: Dan Espen <[email-masked]>
Date: Wed, 14 Jun 2000 10:10:12 -0400

> FvwmCommand will look in /var/tmp and then /tmp before failing.

A Google search using "/var/tmp vs /tmp" convinces me that /var/tmp is
the  preferred place.  Trying /tmp next  seems logical.  Another issue
with /tmp is that  cron scripts to clean  it are more common than cron
scripts to clean /var/tmp.

I still like the S_ISFIFO test.

---

From: [email-masked] (Paul D. Smith)
Date: 14 Jun 2000 11:00:21 -0400

%% Tim Phipps <[email-masked]> writes:

  tp> How's this for a plan:

  tp> FvwmCommandS tries the following in /var/tmp and /tmp: *) If the
  tp> pipes already exist kill off any running FvwmCommandS and remove
  tp> them. (this happens already) *) Create new pipes.  *) Open the
  tp> pipes, stat them and check for S_ISFIFO and correct mode.

  tp> FvwmCommand will look in /var/tmp and then /tmp before failing.

  tp> Should I do this?

The canonical way to manage DoS, etc. attacks via public directories and
temporary files like this is to create a subdirectory, with permissions
only for the user, and put all interesting items there.

The directory should be named with the PID, so it's unique, or using
mktemp() or similar.

Personally, I think it would be A Good Thing if FVWM itself created a
directory like this, and provided the information on it to all its
modules (via an environment variable or the command line) so they could
utilize it for whatever purpose they wished.  That would save,
potentially, a lot of individual module effort, and keep things in the
tmp directory cleaner.

The command line would be safer, although less backward-compatible; if
we do it via the environment we should be careful to not add it to the
environment of anything but modules (not normal commands), and even then
it's an information leak since modules can spawn shells, etc.

Use any method you like to come up with the directory name; I prefer
mktemp() or similar because the PID is too easily guessed and used in
DoS.  What you do is run mkdir with the appropriate mode (0700).  The
mkdir(2) system call will fail if the directory already exists, so if it
works you are guaranteed to get a new directory that only the user can
modify (if the mkdir fails, fvwm should exit with some _descriptive_
error message, of course--maybe it could retry a few times).

Now you can create simply-named files (FvwmCommandS) there, without
needing the display or PID or whatever appended to the filename.

The thing to remember is the cleanup, though; when FVWM is exiting it
needs to remove the contents of the directory and the directory itself.

---

From: Tim Phipps <[email-masked]>
Date: Wed, 14 Jun 2000 16:08:45 +0100

> potentially, a lot of individual module effort, and keep things in the

How would FvwmCommand know where to look? It's not in any way related to
the fvwm2 process, the only thing in common is the $DISPLAY variable.

Cheers,
Tim.

---

From: [email-masked] (Paul D. Smith)
Date: 14 Jun 2000 11:42:07 -0400

tp> How would FvwmCommand know where to look? It's not in any way
  tp> related to the fvwm2 process, the only thing in common is the
  tp> $DISPLAY variable.

Oh right.  Duh.

Well, we could use the display in the directory name.  That is _very_
bad.  I dislike it _very_ much.  It means that anyone can block you from
logging in with one simple mkdir, and they wouldn't even have to guess
at the name.

OK.  Here are the options I see:

 1) Punt the idea of an fvwm-wide directory, and have individual modules
    that need named pipes or whatever, create them as they like (they
    could still use the directory method for security).  This is a
    shame, but it means that malicious users could block you from
    running FvwmCommandS, but not from running FVWM itself.

    Alternatively, FVWM could try to create the directory but keep going
    if it fails, and then modules that needed it would not be startable
    but you could run the rest of FVWM.

    It's still unfortunate that it's so simple to break this; just
    killing FVWM such that it doesn't have a chance to clean up will do
    that.  Maybe if the directory exists when FVWM starts it could try
    to clean it up first, then run the mkdir(2).  If the directory
    existed from a previous invocation, the user will have all the
    permissions he needs to clean up.

 2) Have FVWM use mktemp(), then put the name in the environment for
    _all_ children, not just modules.  This way, any invocation of
    FvwmCommand that was a child of FVWM would automatically be able to
    find the right directory.  That works when you're trying to control
    FVWM from within any process started by FVWM or its children.

    It wouldn't help if you were running FvwmCommand from another
    system, or via cron, or whatever, though.  It also wouldn't work for
    xterms created by .xsession or .xinit instead of through FVWM's Init
    and Restart functions.  In this case FvwmCommand would have to be
    enhanced to take the directory name as an argument.  This is kind of
    hokey.

 3) Have FVWM create the directory using mktemp(), then write the name
    of the directory to a file in the user's home directory.  The file
    would be something like ".fvwm-$DISPLAY" or whatever.  Clients like
    FvwmCommand could read the file to get the "real" directory name.
    As long as the user's home directory is secure, this should work.
    Another nice thing about this is that the logic deciding where to
    create the directory (/var/tmp vs. /tmp etc.) all resides in only
    one place: FVWM itself.  That makes it easy to allow for some kind
    of override, as you only need to do it in one place.

    It seems roundabout and complicated, but probably something like
    this is, overall, the safest method.

---

From: Mikhael Goikhman <[email-masked]>
Date: Thu, 15 Jun 2000 01:50:15 +0300

> potentially, a lot of individual module effort, and keep things in the

fvwm already prepares such directory for all modules, it is $FVWM_USERDIR,
defaulting to $HOME/.fvwm.

I would personally not play with tmp dirs. This may create more problems
than solve (unique names, permissions, cleaning, privacy). FvwmCommandS
can simply exit with an error message suggesting either to define another
value for $FVWM_USERDIR (/tmp/$USER), or specify command line arguments.

If you already want to write something to /tmp, do it only when creating
pipes in FVWM_USERDIR is failed, this will pass for most of users. IMHO.

Regards,
Mikhael.

---

From: Tim Phipps <[email-masked]>
Date: Thu, 15 Jun 2000 10:31:58 +0100

> pipes in FVWM_USERDIR is failed, this will pass for most of users. IMHO.

Unfortunately it won't work for some users with NFS mounted home
directories. I wouldn't bank on there being a reliable means of
detecting this type of failure. We already know that creating the pipe
appears to work when in fact it doesn't. I wouldn't be suprised to find
that testing the results after creation is vulnerable to `features' in
NFS attribute caching as well.

Cheers,
Tim.

---

From: Tim Phipps <[email-masked]>
Date: Thu, 15 Jun 2000 13:16:47 +0100

"Paul D. Smith" wrote:
>  1) ...
>  2) ...
>  3) ...

I think we're too close to 2.4 to start putting stuff like this into
fvwm. Post 2.4 I'd like to see fvwm having a command port/socket/pipe
that it advertizes on the display so that FvwmCommand and FvwmConsole
can both operate over the network. We can fix security at that point. In
the mean time I'm going to move the FvwmCommand pipes from $HOME to
/var/tmp or /tmp. 

Cheers,
Tim.

---

From: [email-masked] (Paul D. Smith)
Date: 15 Jun 2000 10:09:54 -0400

>> this is, overall, the safest method.

  tp> I think we're too close to 2.4 to start putting stuff like this
  tp> into fvwm. Post 2.4 I'd like to see fvwm having a command
  tp> port/socket/pipe that it advertizes on the display so that
  tp> FvwmCommand and FvwmConsole can both operate over the network. We
  tp> can fix security at that point. In the mean time I'm going to move
  tp> the FvwmCommand pipes from $HOME to /var/tmp or /tmp.

OK.