Some files in /usr/lib/openoffice are owned by uid 654, which doesn't give any sense. Should be owned by root, shouldn't they? This applies for the openoffice-2.0.1 as well as openoffice-2.0.1-r1. Emerge --info goes here, but I think it is unnecessary: Portage 2.0.54 (default-linux/x86/2006.0, gcc-3.4.5, glibc-2.3.4.20040808-r1,glibc-2.3.5-r2, 2.6.15-gentoo-r1 i686) ================================================================= System uname: 2.6.15-gentoo-r1 i686 AMD Athlon(tm) XP 3200+ Gentoo Base System version 1.6.14 distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] ccache version 2.3 [enabled] dev-lang/python: 2.4.2 sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.13, 2.59-r7 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 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O3 -march=athlon-xp -m3dnow -msse -mfpmath=sse -mmmx -pipe -fforce-addr -fomit-frame-pointer -funroll-loops -frerun-cse-after-loop -frerun-loop-opt -falign-functions=4 -maccumulate-outgoing-args -ffast-math -fprefetch-loop-arrays" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O3 -march=athlon-xp -m3dnow -msse -mfpmath=sse -mmmx -pipe -fforce-addr -fomit-frame-pointer -funroll-loops -frerun-cse-after-loop -frerun-loop-opt -falign-functions=4 -maccumulate-outgoing-args -ffast-math -fprefetch-loop-arrays" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LANG="cs_CZ" LINGUAS="cs" 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="x86 3dnow 3dnowext X acl acpi alsa apache2 arts artswrappersuid asf avi bash-completion berkdb bitmap-fonts bzip2 cdb cdr cli crypt ctype cups curl dba directfb dri dvb dvd dvdr emboss encode exif expat fastbuild fbcon ffmpeg font-server force-cgi-redirect fortran ftp gd gdbm gif glut gpm gtk2 icq idn imagemagick imlib java javascript joystick jpeg kde lcms ldap libg++ libwww lirc lm_sensors mad memlimit mikmod mmx mmxext mng mozilla mp3 mpeg ncurses network nls nptl nptlonly nsplugin nvidia offensive ogg openal opengl oscar oss pam pcre pdflib perl png posix python qt quicktime readline real rtc samba scanner sdl session simplexml soap sockets spl sse ssl svga tcpd tiff tokenizer truetype truetype-fonts type1-fonts udev usb vorbis win32codecs wxgtk1 xine xml xml2 xosd xsl xv xvid zlib linguas_cs userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LC_ALL, LDFLAGS
Could that uid by any chance belong to the portage user on your system? In my install some files are erronously owned by the portage user and group. As an aside, you should probably clean out your CFLAGS. Don't include -ffast-math etc. as it will break things.
(In reply to comment #1) > Could that uid by any chance belong to the portage user on your system? In my > install some files are erronously owned by the portage user and group. > > As an aside, you should probably clean out your CFLAGS. Don't include > -ffast-math etc. as it will break things. > UID 654 has no username assigned. It's just a number on my system. Btw. I haven't noticed any problems with -ffast-math for two years...
Can see that, in my case they are owned by UID 11012. The question is: Is this a real problem?
(In reply to comment #3) > Can see that, in my case they are owned by UID 11012. The question is: Is this > a real problem? > I believe it is a problem. Imagine that there exists an user with this ID in your system. He would be able to manipulate those files, delete them or even modify them to fit his own needs. This should be definitely fixed.
I agree with Milan, this is a potential security issue that should not go unfixed. Random users are really dangerous. It is probably caused by certain files some tarbal having the wrong owners and upacking them the wrong way (with persisting owners). To temporarilly fix this we could append: "chown -R root:root ${D}" to the install phase
Reassigning to security. Openoffice please advise and provide an updated ebuild as necessary. My openoffice-bin-2.0.2 installtion doesn't seem to suffer from this.
I've just commited an update to the ebuild, which fixes this problem, permissions are now right for me. So what would you say is the next step?
I tend to think we should just close it here. Security devs any other opinion?
Yes I agree with closing it without GLSA. The odds that a real user is attributed to that UID, that the system is multiuser and that this precise user has evil intents makes this a low-risk potential security hole. Milan: thx for reporting this, are you OK with us opening the bug for the whole world to see ?
i'm also voting for no glsa. closing, of course feel free to reopen if you disagree.
(In reply to comment #9) > Yes I agree with closing it without GLSA. The odds that a real user is > attributed to that UID, that the system is multiuser and that this precise user > has evil intents makes this a low-risk potential security hole. > > Milan: thx for reporting this, are you OK with us opening the bug for the whole > world to see ? > Hello, it is completely OK. Thanx for resolving this.
