After afresh install all the way from a bootstrap.sh up until a kernel build, reboot, finish a find / -uid 1000 > file shows that there are MAJOR files owned by uid 1000 that should not be so.. This is a major security risk as whoever the first user added will own files that should be owned by root. Here is a list of stuff found on a base system by Chris from #gentoo-sparc. # find / -uid 1000 > blah # cat blah /tmp /var /var/tmp /var/db /var/db/pkg /var/db/pkg/sys-apps /var/db/pkg/sys-devel /var/db/pkg/sys-devel/binutils-2.11.92.0.12.3-r2 /var/db/pkg/sys-kernel /var/db/pkg/sys-kernel/linux-headers-2.4.18 /var/db/pkg/sys-libs /var/cache /var/cache/edb /var/run /var/lock /var/lock/subsys /var/log /var/log/news /var/spool /var/spool/locate /var/lib /var/lib/misc /etc /etc/env.d /etc/cron.hourly /etc/cron.daily /etc/cron.weekly /etc/cron.monthly /etc/modules.d /etc/conf.d /etc/ppp /etc/init.d /etc/skel /etc/runlevels /etc/runlevels/default /etc/runlevels/boot /etc/runlevels/nonetwork /etc/runlevels/single /sbin /usr /usr/bin This list does not include blackdown-jdk which I later emerged and had the same problem with.
I had this exact same problem. It was my first install of gentoo and on sparc to boot ;) and I figured I just did something funky. It looks like mostly first level directories were affected. I cleaned them up by hand. -Wence
I thought this was oopsed permissions in the stage1 tarball? (stage1-sparc-1.1a-r1.tbz2) Is this still going to be a problem now that 1.4 is more or less ready? certainly the date on the files on ibiblio precede the date on the bug report so anyone using the 1.1a tarball will experience this.
latest blackdown appears not to exhibit this problem
this is issue has been fixed. closing bug
Closing
