Summary: | cp problem/error with acl/attr | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | djinnZ <nicola.rauseo> |
Component: | [OLD] Core system | Assignee: | Gentoo's Team for Core System packages <base-system> |
Status: | RESOLVED WORKSFORME | ||
Severity: | normal | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
djinnZ
2006-02-03 05:14:50 UTC
Reopen with output of 'emerge -pv coreutils attr' and mount commands. (In reply to comment #1) > Reopen with output of 'emerge -pv coreutils attr' and mount commands. > /dev/hdb1 on / type reiserfs (rw,noatime,notail) proc on /proc type proc (rw) sysfs on /sys type sysfs (rw) udev on /dev type tmpfs (rw,nosuid) devpts on /dev/pts type devpts (rw) /dev/hdb3 on /var type reiserfs (rw,noatime,notail) shm on /dev/shm type tmpfs (rw,noexec,nosuid,nodev) /dev/hdc1 on /home type reiserfs (rw) /dev/hdc7 on /home/p2p type reiserfs (rw) /dev/hdc6 on /opt/prg type reiserfs (rw) /dev/hdc5 on /opt/mitos type reiserfs (rw) /dev/hdc3 on /var/backup type reiserfs (rw) usbfs on /proc/bus/usb type usbfs (rw,devmode=0664,devgid=85) nfsd on /proc/fs/nfs type nfsd (rw) rpc_pipefs on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw) /dev/hdg1 on /mnt/gentoo type reiserfs (rw) /dev on /mnt/gentoo/dev type none (rw,bind) /sys on /mnt/gentoo/sys type none (rw,bind) /proc on /mnt/gentoo/proc type none (rw,bind) /usr/portage/distfiles on /mnt/gentoo/usr/portage/distfiles type none (rw,bind) I must correct my report, as non root user cp /dev/something create a zero file if the device is not readable in case is readable a copy of the device. By example a user can do cp /dev/hda1 /home/username/hda1 if hda1 is rw-rw-rw- the user has a new device file owned by itself. The error cant be easy reproduce by my opinion but is a serius problem. Can I suggest (cp -f /dev/null test; [-c test]&& die) a test at end of the building of coreutils/attr/acl? :-) reemerging acl(broken), attr and coreutils (in a emerge -e world) solve the security problem but not the error. thx for suggestion, for now I think was a broken library (I have reemerged the whole system to the new processor after my old fileserver, a PII, was down last week) but I not have the knowlege and the time to investigate the problem. You still haven't posted coreutils not acl or attr versions... I have forget to say that the error must be after the change from the attr-2.4.19 to 2.4.24 at end of last month. The older system on laptop (an AMD64 they have build the original system for the PII) works good and emerging the binary package from this sistem remove the error (but not the depend). and I have forget the requested info, sorry. [ebuild R ] sys-fs/xfsdump-2.2.30 -debug 0 kB [ebuild R ] sys-fs/xfsprogs-2.7.3 +nls 0 kB [ebuild R ] sys-apps/attr-2.4.24 -debug +nls 0 kB [ebuild R ] sys-apps/coreutils-5.2.1-r7 +acl -build +nls (-selinux) -static 0 kB [ebuild R ] sys-apps/acl-2.2.32 -debug +nls 0 kB try upgrading coreutils to 5.93, it's seen some acl/attr updates (In reply to comment #5) > try upgrading coreutils to 5.93, it's seen some acl/attr updates > problem solved, thanks for help. But i warn about the problem of a broken acl/attr/coreutils and what can do. In emerging i can have a conf file who discrds all changes or a zero sed script and a non root user can obtatin a self owned copy of any device if is redable (not tested but i think so). Excuse me if i have not tink to backup a copy of broken binary for furter invenstigation. The only reason for this uncommon error I can imagine is the conversion between diffent optimiziation (PII to athlon) and diffent library version at same time who causes random errors in binary code produced. |