When invoking tilp as a normal user (maybe it is important that it is a "localized user" [LANG="de_DE@euro"]) tilp crashes with a segmentation fault: --- tilp --- martin at wechner ~ $ LANG="en" tilp tilp : TiLP - Version 6.74, (C) 1999-2004 Romain Lievin <roms@tilp.info> Speicherzugriffsfehler --- "Speicherzugriffsfehler" is Segmentation Fault in English ;) This does not happen when tilp is called by root (not localized). Then everything works fine. I've also re-emerged tilp and its dependencies libti* Reproducible: Always Steps to Reproduce: 1. emerge =app-sci/tilp-6.74 2. su - <normal_user> 3. tilp Actual Results: Segfaulted Expected Results: Should not # emerge info Portage 2.0.51_rc10 (default-x86-1.4, gcc-3.4.2, glibc-2.3.4.20041006-r0, 2.6.9-ck1 i686) ================================================================= System uname: 2.6.9-ck1 i686 AMD Duron(tm) Gentoo Base System version 1.5.3 distcc 2.18 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] Autoconf: sys-devel/autoconf-2.59-r5 Automake: sys-devel/automake-1.8.5-r1 Binutils: sys-devel/binutils-2.15.92.0.2-r1 Headers: sys-kernel/linux-headers-2.4.19,sys-kernel/linux-headers-2.4.22 Libtools: sys-devel/libtool-1.5.2-r5 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-march=i686 -O3 -pipe -mmmx -msse -m3dnow -mfpmath=sse -ftracer" CHOST="i686-pc-linux-gnu" COMPILER="" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=i686 -O3 -pipe -mmmx -msse -m3dnow -mfpmath=sse -ftracer" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache distlocks sandbox" GENTOO_MIRRORS="ftp://mirror.switch.ch/mirror/gentoo/ http://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ http://gentoo.osuosl.org http://www.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="3dnow 3dnowex X aalib acl acpi acpi4linux alsa apache2 apm avi berkdb bitmap-fonts blender-game bonobo bootsplash bzlib cdparanoia cdr clanVoice crypt cups dba dedicated dga divx4linux doc dvd encode escreen f77 fbcon foomaticdb freetype gd gdbm gif gnome gpm gtk gtk2 imagemagick imlib java jpeg libg++ libwww mad mailwrapper mbox mikmod mmx mmx2 motif mpeg mysql ncurses net nls oggvorbis opengl oss pam pdflib perl png python quicktime radeon readline rtc ruby samba sdl session shared silverxp slang sockets spell spl sse ssl stencil-buffer svga tcltk tcpd tetex tokenizer truetype usb videos wxwindows x86 xchattext xfs xml xml2 xmms xpm xprint xsl xv zlib"
Since bug #40263 had to do something with locales and crashes I tried $ LC_ALL=C tilp but I still get the seg fault when run under a "normal" user.
Is there perhaps some configuration file saved for this user tilp ties to read? ~/.tilp perhaps? Make a backup copy of it and delete it, please.
There was a ~/.tilp but deleting that file did not solve the problem.
Please attach (not paste) an strace log: strace -o log -f tilp
Oh, and please check if /tmp/tilp.log exists.
/tmp/tilp.log existed and you won't believe it: deleting it solved this for me! I cannot say why it solved it, however, since I did not backup it. However I'm getting now a new error when using tilp: Starting tilp works, calculator (TI-Voyage 200) is connected ready, SilverLink is detected correctly, but tilp reports when clicking "Ready" or any other operation "Msg: Invalid host ID. Cause: TiLP received an unexpected Machine ID, probably due to a transmission error." With Windows and the tools provided by TI it works perfectly instead.
Having a look at the logging source I noticed that it simply writes to /tmp/tilp.log without deleting it before or checking if it is a symlink. So this could be used by a malicious user to overwrite any file another person running tilp has access to. Masking this package and assiging to security. I think a warning should be issued to our users. I'll put a message on the tilp sourceforge bug tracker.
Update: This has been fixed in the latest release which we don't have yet. Working on it.
Would be nice if ppc could move 6.76 into stable ASAP.
Stable on ppc. It does not crash, although I didn't tested it with my TI92+ attached.
Maybe a GLSA would be nice now? The only remaining version in portage is 6.76 which does not have this tmpfile problem.
Security please vote for GLSA need. Pro : We issued GLSAs for other recent tmpfile vulns Con : This is a misc package and I don't think it's run by the root user very often.
For the sake of consistency with tempfile vulns, I vote yes.
I tried to figure out why I keep getting "Msg: Invalid host ID." messages. Even getting them with And I think I found it: /dev/tiusb0 and maybe other necessary devices are not created when the cable is plugged in! I'm getting the messages: Dec 3 23:21:48 wechner usb 2-2: new full speed USB device using address 4 Dec 3 23:21:48 wechner drivers/usb/misc/tiglusb.c: firmware revision 2.08 so it is loaded, but as I said _no_ device nodes are created! I'm using ck-sources-2.6.9-r3
Patrick will you look into this please?
Please correct me if I am wrong, but isn't that a kernel driver problem? I don't think tilp should create any device nodes, should it?
Yes, this looks like a kernel/kernelconfig/udev/devfs issue, unrelated to tilp. You plug the thing in, it should create the devices. I suppose tilp has nothing to do about it. We aren't trying to solve all tilp-related issues here, just testing that there is no regression compared to the previous stable version. So unless your tilp device creation was okay with the previous version and now is broken, please file another bug.
Thx. Security please cast your vote on a GLSA for this. I tend to say no.
Comment #18: You're right. It followed the original bug. Shall I open a new bug for that issue?
Martin if you have the same problem with the previous version file a new bug. Otherwise it seems like a regression and should be handled on this bug.
Had the same problem with the old version. New bug #73719 Thanks for that hint.
Security please cast your vote on this one.
I vote no -- package is really not the kind you would run as root on a multiuser setup (or is it ?). Please reopen if you happen to disagree.
