Re: CVS griph: fix tempfile vulnerabilities in FvwmCommand (bug
On Wed, Jul 12, 2006 at 01:28:45AM +0200, Viktor Griph wrote: On Tue, 11 Jul 2006, Dominik Vogt wrote: On Tue, Jul 11, 2006 at 10:16:09AM -0500, fvwm-workers wrote: CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: griph 06/07/11 10:16:09 Modified files: . : ChangeLog NEWS configure.ac modules: ChangeLog modules/FvwmCommand: FvwmCommand.1.in FvwmCommand.c FvwmCommandS.c fifos.c Log message: fix tempfile vulnerabilities in FvwmCommand (bug #2791). Can you explain what you actually did, please? Sure. First: When deciding on the default path the three files that are to be used are tested with lstat (or stat if lstat is unavalable) to have the same owner as the process owner, not have nore than one hard link and not be a directory nor a symbolic link. If any of the tests fail the path will be redirected to $FVWM_USERDIR instead of /var/tmp to avoid attacks blocking the module. If some tests are impossible to do they are concidered OK. Actually, since we are creating the file with O_CREAT | O_EXCL, there is no chance of a symlink attack (because symlinks exist even if they do not point to anything). Second: All open() calls use O_NOFOLLOW if that flag is defined. Good, but I don't want new ifdefs in the code. Instead, please add this to the end of the AH_VERBATIM macro _ZEND_EXPLICIT_DEFINITIONS in configure.ac, beginning at line 1195: #ifndef O_NOFOLLOW #define O_NOFOLLOW 0 #endif This snippet is added to the end of config.h. Afterwards you can use O_NOFOLLOW without ifdefs. As a rule of thumb, never put any ifdefs in a .c file (or better: anywhere). I believe this should be enough, We really shouldn't be using public tempdirs at all. I wasn't aware that we are using /var/tmp. but if one are really paranoid one could add checks of the opened files in FvwmCommand.c to verify that they are fifos with correect permissions. Ah, but it's too late if the file is open already. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
CVS domivogt: * Removed ifdefs from fifos.c.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt06/07/12 03:27:26 Modified files: . : ChangeLog configure.ac libs : Makefile.am modules: ChangeLog modules/FvwmCommand: FvwmCommand.h fifos.c Log message: * Removed ifdefs from fifos.c. * Added a compat header file libs/fvwm_sys_stat.h to wrap stat.h compat issues.
Re: CVS griph: fix tempfile vulnerabilities in FvwmCommand (bug
On Wed, Jul 12, 2006 at 09:50:01AM +0200, Dominik Vogt wrote: On Wed, Jul 12, 2006 at 01:28:45AM +0200, Viktor Griph wrote: Good, but I don't want new ifdefs in the code. Instead, please add this to the end of the AH_VERBATIM macro _ZEND_EXPLICIT_DEFINITIONS in configure.ac, beginning at line 1195: #ifndef O_NOFOLLOW #define O_NOFOLLOW 0 #endif This snippet is added to the end of config.h. I' have done that part myself because I had to include fcntl.h too. The ifdefs in the code still have to be removed. As a rule of thumb, never put any ifdefs in a .c file (or better: anywhere). I.e. fetuere tests belong into configure.ac. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
CVS domivogt: * Compile fix.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt06/07/12 03:27:50 Modified files: modules/FvwmCommand: fifos.c Log message: * Compile fix.
Re: ChangeLog vs modules/ChangeLog ?
On 7/12/06, Dan Espen [EMAIL PROTECTED] wrote: seventh guardian [EMAIL PROTECTED] writes: Hi. I have a question regarding the use of the ChangeLogs. Obviously, changes to the fvwm core are reported in the root ChangeLog. But what about changes to modules? I ask this because I've allways logged my changes to the root one, but now think I should have done it to modues/ChangeLog. On the other hand, there are lots of module changes in the root changelog.. So, what is our ChangeLog policy? If it is module stuff - modules/ChangeLog, rest - ChangeLog, then I guess module stuff should be moved to the correct modules/ChangeLog. If not, then we would be better served with just one ChangeLog, in wich case we should merge both. The Changelogs were getting huge so they were split up. Using Emacs, you find the right one using C-x 4 a. Otherwise it's the first one above the directory your in. Hum.. Ok, then there are lots of entries in the root ChangeLog not belonging there.. Should they be moved to the right place? Renato -- Dan Espen E-mail: [EMAIL PROTECTED]
Re: CVS domivogt: * Removed ifdefs from fifos.c.
On Wed, Jul 12, 2006 at 03:27:26AM -0500, FVWM CVS wrote: CVSROOT: /home/cvs/fvwm Module name: fvwm Changes by: domivogt 06/07/12 03:27:26 Modified files: . : ChangeLog configure.ac libs : Makefile.am modules : ChangeLog modules/FvwmCommand: FvwmCommand.h fifos.c Log message: * Removed ifdefs from fifos.c. * Added a compat header file libs/fvwm_sys_stat.h to wrap stat.h compat issues. Might I suggest the #ifdefs reasoning is added to docs/CONVENTIONS ? I think it would be useful there. -- Thomas Adam -- If I were a witch's hat, sitting on her head like a paraffin stove, I'd fly away and be a bat. -- Incredible String Band.
CVS domivogt: * Added missing file.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt06/07/12 08:28:31 Added files: libs : fvwm_sys_stat.h Log message: * Added missing file.
CVS domivogt: * Print initial size with ExplainWindowPlacement too.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt06/07/12 08:28:11 Modified files: . : ChangeLog fvwm : placement.c Log message: * Print initial size with ExplainWindowPlacement too.
Re: CVS griph: fix tempfile vulnerabilities in FvwmCommand (bug
Dominik Vogt wrote:
On Wed, Jul 12, 2006 at 01:28:45AM +0200, Viktor Griph wrote:
but if one are really paranoid one could
add checks of the opened files in FvwmCommand.c to verify that they are
fifos with correect permissions.
Ah, but it's too late if the file is open already.
Is there some reason that fstat({2,P}) isn't usable? It takes an open
file descriptor.
Re: FvwmPager: Compilation fix when --enable-debug-msgs is set
On Tue, Jul 11, 2006 at 11:44:22PM +0100, seventh guardian wrote: BTW, is it my impression or you don't have an @ on your ChangeLog email? I have. It is mostly antispam measure. Here in Russia we call this @ symbol in email addresses - dog. Best wishes -- Serge Koksharov, Free Software user supporter GPG public key ID: 0x3D330896 (pgp.mit.edu) Key fingerprint: 5BC4 0475 CB03 6A31 0076 82C2 C240 72F0 3D33 0896
Removing gnome support from FvwmGtk
Hello. Having looked at FvwmGtk code, I realise there's no need for gnome support, as no gnome specific functions are used. So, there's no advantage of calling gnome_init vs gtk_init. And from what I see, the gnome support has been several times mis-used by precompiled distros (forcing the instalation of gnome libs when they are not required at all). So, I ask if we can remove the gnome support from FvwmGtk. BTW, please correct me if I'm wrong. Cheers, Renato
Re: Removing gnome support from FvwmGtk
On Wed, Jul 12, 2006 at 11:24:57PM +0100, seventh guardian wrote: Hello. Having looked at FvwmGtk code, I realise there's no need for gnome support, as no gnome specific functions are used. So, there's no advantage of calling gnome_init vs gtk_init. And from what I see, the gnome support has been several times mis-used by precompiled distros (forcing the instalation of gnome libs when they are not required at all). So, I ask if we can remove the gnome support from FvwmGtk. I've been saying this for years -- yet no one would listen. I am in favour of it. -- Thomas Adam -- If I were a witch's hat, sitting on her head like a paraffin stove, I'd fly away and be a bat. -- Incredible String Band.
Re: Removing gnome support from FvwmGtk
On 7/12/06, Thomas Adam [EMAIL PROTECTED] wrote: On Wed, Jul 12, 2006 at 11:24:57PM +0100, seventh guardian wrote: Hello. Having looked at FvwmGtk code, I realise there's no need for gnome support, as no gnome specific functions are used. So, there's no advantage of calling gnome_init vs gtk_init. And from what I see, the gnome support has been several times mis-used by precompiled distros (forcing the instalation of gnome libs when they are not required at all). So, I ask if we can remove the gnome support from FvwmGtk. I've been saying this for years -- yet no one would listen. I am in favour of it. Humm.. After a bit more dig up, it seems that gnome support is not just that.. It's also the gnome wm hints support.. it may be important, as this allows fvwm to integrate with gnome desktop (pagers and stuff). But in what refers to FvwmGtk, it works exactly the same without gnome support. The final question is, is it worth remove gnome support from FvwmGtk if the rest of fvwm still needs it... Renato -- Thomas Adam -- If I were a witch's hat, sitting on her head like a paraffin stove, I'd fly away and be a bat. -- Incredible String Band.
Re: Removing gnome support from FvwmGtk
On Wed, Jul 12, 2006 at 11:44:51PM +0100, seventh guardian wrote: But in what refers to FvwmGtk, it works exactly the same without gnome support. The final question is, is it worth remove gnome support from FvwmGtk if the rest of fvwm still needs it... FvwmGTK is just that -- turning various bits and bobs to use GTK. The fact that the GNOME developers seem to think the detritous they call code in GTK is their doing needs removing quite frankly. The G in GTK does not stand for GNOME. The sooner the GNOME developers realise this, the better for everyone. Note that the superfluous libs that the Debian maintainer still has with fvwm-gnome is still his fault, but he won't listen to requests for its removal. -- Thomas Adam -- If I were a witch's hat, sitting on her head like a paraffin stove, I'd fly away and be a bat. -- Incredible String Band.
Re: Removing gnome support from FvwmGtk
seventh guardian a écrit : On 7/12/06, Thomas Adam [EMAIL PROTECTED] wrote: On Wed, Jul 12, 2006 at 11:24:57PM +0100, seventh guardian wrote: Hello. Having looked at FvwmGtk code, I realise there's no need for gnome support, as no gnome specific functions are used. So, there's no advantage of calling gnome_init vs gtk_init. And from what I see, the gnome support has been several times mis-used by precompiled distros (forcing the instalation of gnome libs when they are not required at all). So, I ask if we can remove the gnome support from FvwmGtk. I've been saying this for years -- yet no one would listen. I am in favour of it. Humm.. After a bit more dig up, it seems that gnome support is not just that.. It's also the gnome wm hints support.. it may be important, as this allows fvwm to integrate with gnome desktop (pagers and stuff). yes, but only for gnome 1, so ... But in what refers to FvwmGtk, it works exactly the same without gnome support. The final question is, is it worth remove gnome support from FvwmGtk if the rest of fvwm still needs it... Not exactly (bug report system, if I remember some discussions on this list). This known as, I am in favor of removing gnome support in FvwmGtk. Olivier
Re: Removing gnome support from FvwmGtk
On 7/13/06, Olivier Chapuis [EMAIL PROTECTED] wrote: seventh guardian a écrit : On 7/12/06, Thomas Adam [EMAIL PROTECTED] wrote: On Wed, Jul 12, 2006 at 11:24:57PM +0100, seventh guardian wrote: Hello. Having looked at FvwmGtk code, I realise there's no need for gnome support, as no gnome specific functions are used. So, there's no advantage of calling gnome_init vs gtk_init. And from what I see, the gnome support has been several times mis-used by precompiled distros (forcing the instalation of gnome libs when they are not required at all). So, I ask if we can remove the gnome support from FvwmGtk. I've been saying this for years -- yet no one would listen. I am in favour of it. Humm.. After a bit more dig up, it seems that gnome support is not just that.. It's also the gnome wm hints support.. it may be important, as this allows fvwm to integrate with gnome desktop (pagers and stuff). yes, but only for gnome 1, so ... Oh! Didn't know that. But in what refers to FvwmGtk, it works exactly the same without gnome support. The final question is, is it worth remove gnome support from FvwmGtk if the rest of fvwm still needs it... Not exactly (bug report system, if I remember some discussions on this list). This known as, I am in favor of removing gnome support in FvwmGtk. And considering the above, what about removing the whole gnome support from fvwm? Olivier
FAQ Q7.17 error?
Hello, In question 7.17 of the FVWM FAQ Autohiding FvwmButtons or other windows module FvwmAuto launched like this: + I Module FvwmAuto FvwmAutohide -menter enter_handler But from reading manpage source code of this module I figured out that it doesn't accept aliases, right? So, I think module invocation should look like this: + I Module FvwmAuto -menter enter_handler Bye -- Serge Koksharov, Free Software user supporter GPG public key ID: 0x3D330896 (pgp.mit.edu) Key fingerprint: 5BC4 0475 CB03 6A31 0076 82C2 C240 72F0 3D33 0896
Tabs implementation question
Hello, I'm trying to find out how to have multiple windows sharing the same frame. I'm playing with FvwmTabs but I also want to experiment with a simpler implementation on my own. I wrote something like the following in the main fvwm code. Add tab: (client is the fw-wins.client from another frame) XReparentWindow(dpy, client, fw-wins.parent, 0, 0); XResizeWindow(dpy, client, fw-frame_g.width, fw-frame_g.height); XLowerWindow(dpy, client); XUnmapWindow(dpy, client); Next tab: (fw-wins.client is advanced by a linked list) XMapWindow(dpy, fw-wins.client); XRaiseWindow(dpy, fw-wins.client); XSaveContext(dpy, fw-wins.client, FvwmContext, (caddr_t) fw); rectangle frame_g = fw-frame_g; frame_force_setup_window( fw, frame_g.x, frame_g.y, frame_g.width, frame_g.height, True); When I switch to another tab, the window works as normal except it doesn't recieve FocusIn/Out events. This stops the focus decor from changing when the mouse is in the window. When I switch back to the first tab, it works properly. There seems to be something special about the first client window because it was originally in that frame. I thought setting FvwmContext would give each client the exact same structure but it doesn't. HandleFocusIn is never called except for the first window. I'm just wondering, what is the solution to this? David
Re: Tabs implementation question
Hi David, I'm trying to find out how to have multiple windows sharing the same frame. I'm playing with FvwmTabs but I also want to experiment with a simpler implementation on my own. Simpler? H. I wrote something like the following in the main fvwm code. Add tab: (client is the fw-wins.client from another frame) XReparentWindow(dpy, client, fw-wins.parent, 0, 0); XResizeWindow(dpy, client, fw-frame_g.width, fw-frame_g.height); XLowerWindow(dpy, client); XUnmapWindow(dpy, client); Next tab: (fw-wins.client is advanced by a linked list) XMapWindow(dpy, fw-wins.client); XRaiseWindow(dpy, fw-wins.client); XSaveContext(dpy, fw-wins.client, FvwmContext, (caddr_t) fw); rectangle frame_g = fw-frame_g; frame_force_setup_window( fw, frame_g.x, frame_g.y, frame_g.width, frame_g.height, True); When I switch to another tab, the window works as normal except it doesn't recieve FocusIn/Out events. This stops the focus decor from changing when the mouse is in the window. When I switch back to the first tab, it works properly. There seems to be something special about the first client window because it was originally in that frame. I thought setting FvwmContext would give each client the exact same structure but it doesn't. HandleFocusIn is never called except for the first window. I'm just wondering, what is the solution to this? You need to use XSetInputFocus(). SCoTT. :)
