g15composer > 2.1 has a rather weird way of acting on my AMD64 system, which I corrected. A stock g15composer-3.0.2 will start normally, and exit as soon as I open its command pipe for input with a [path to pipe] : Bad file descriptor This error looked like a simple perror(), so I went to check and found two, along with somewhing weird. In essence, g15composer > 2.1 uses a lex-generated syntax parser. The parser uses a yyset_in() function to set which file (in this case, FIFO) to analyze. This function has a void return type where it is defined, but g15composer uses it this way: -------------------- BEGIN CODE SNIPPET -------------------- if ((yyset_in(fopen (param->fifo_filename,"r"), param->scanner)) == 0) { perror (param->fifo_filename); param->leaving = 1; } --------------------- END CODE SNIPPET --------------------- No wonder then the application always quits with an error, since yyset_in() has the void return type (and thus always returns 0) ... What I did was modify this to properly open the FIFO, check if this was done correctly, exit in the same way as above if not, or give its handle to the syntax parser otherwise. It works flawlessly now. Another small but useful thing is that I modified the created FIFO's permission to allow everybody to write in them. Since g15composer has to be run as root under Gentoo (to create /var/run/g15composer), without this, user processes can send a pipe create command to g15composer, but can't write in the newly-created FIFO since its permissions (write-only to user and group, here both root) disallow this. The patch for these two fixes is included here. Please, have a look at this and assert whether this is useful. Maybe I've misunderstood something. For the sake of completeness, here's the output from emerge --info: ------------------- BEGIN emerge --info ------------------- Portage 2.1.1-r1 (default-linux/amd64/2006.0, gcc-3.4.4, glibc-2.3.5-r2, 2.6.18-gentoo-r3 x86_64) ================================================================= System uname: 2.6.18-gentoo-r3 x86_64 AMD Athlon(tm) 64 Processor 3500+ Gentoo Base System version 1.6.14 Last Sync: Sat, 16 Dec 2006 13:50:01 +0000 app-admin/eselect-compiler: [Not Present] dev-java/java-config: 1.3.6-r1, 2.0.28-r1 dev-lang/python: 2.3.5-r2, 2.4.3-r1 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.12-r6 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=k8 -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/share/X11/xkb /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/java-config/vms/ /etc/revdep-rebuild /etc/splash /etc/terminfo /etc/texmf/web2c"CXXFLAGS="-march=k8 -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="http://mirror.switch.ch/mirror/gentoo/ http://gentoo.mirror.solnet.ch" LANG="en_US.utf8" LC_ALL="" LINGUAS="en fr" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage /usr/local/layman/xeffects" SYNC="rsync://rsync.de.gentoo.org/gentoo-portage" USE="amd64 X aac alsa berkdb bitmap-fonts cdparanoia cjk cli cracklib crypt cups dga dlloader dri dvd dvdr dvdread eds elibc_glibc emacs emboss encode fbcon flac foomaticdb fortran gif gnome gpm gstreamer gtk gtk2 iconv ieee1394 imlib input_devices_keyboard input_devices_mouse ipv6 isdnlog jpeg kde kernel_linux linguas_en linguas_fr lm_sensors lzw lzw-tiff mad mp3 mpeg musepack ncurses nls nptl nsplugin nvidia offensive oggvorbis opengl oss pam pcre perl png pppd python qt3 qt4 quicktime readline reflection sdl session spell spl ssl tcpd theora tiff truetype truetype-fonts type1-fonts unicode usb userland_GNU video_cards_fbdev video_cards_nv video_cards_nvidia video_cards_vesa vorbis wxwindows xorg xpm xv zlib" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, PORTAGE_RSYNC_EXTRA_OPTS ------------------- END emerge --info ------------------- Maybe this ought to be reported upstream, too.
Created attachment 104169 [details, diff] g15composer FIFO handling patch The aforementioned patch.
Changing the permissions is not necessary in g15composer itself. I believe it is safer to restrict permissions and then lower them by hand if needed, which is done in the init script shipped with >=g15composer-2.1: # ls -l /var/run/g15composer prwx-w---- 1 root users 0 2006-12-19 18:15 /var/run/g15composer I could think about configuring this via g15composer.confd though, you do have a point there. Does setting the `users' group write not work for you?
I've committed the yyset_in changes upstream. That's really a stupid oversight on my part. The strange part is that it's worked just fine for so long on my system and others. I'll push out g15composer-3.0.3 shortly to include the fix. As for the FIFO permissions issue, I'd prefer to default to 640. As of g15composer-3.0.2, g15composer no longer delete FIFOs from /var/run when it's done with them and also can change its effective UID. This way it's not necessary to run it as root. Simply create /var/run/g15composer, chown it to your user and add -u <username> to the init.d script. This is probably only workable on single user systems, but it's better than having g15composer run as root and allowing random users to create random files with root permissions.
(In reply to comment #3) > As for the FIFO permissions issue, I'd prefer to default to 640. As of > g15composer-3.0.2, g15composer no longer delete FIFOs from /var/run when it's > done with them and also can change its effective UID. This way it's not > necessary to run it as root. Simply create /var/run/g15composer, chown it to > your user and add -u <username> to the init.d script. This is probably only > workable on single user systems, but it's better than having g15composer run as > root and allowing random users to create random files with root permissions. > Good to know. That permissions 'fix' was more of a quick job to make this work at all costs regardless to security. I wish there was a more elegant solution than having to create /var/run/g15composer and change the UID, which makes it single-user, but you're right. In retrospective, this ought to be better than having an exploitable program running as root. Thanks for the answer.
(In reply to comment #4) > In retrospective, this ought to be better than > having an exploitable program running as root. Thanks for the answer. With the FIFO architecture, you can only give it root permission so it can write anywhere or give it user's rights and then all permission handling has to be done by hand. We're waiting for another release before bumping which allows to disable re-using of the same fifo, so multi-user setups can run multiple versions of g15composer. That seems to be a good option in terms of rights.
Fixed both issues with g15composer-3.1 in the tree.
