coreutils update: fedora4 - error: unpacking of archive failed - operation not permit
Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
coreutils update: fedora4 - error: unpacking of archive failed - operation not permit
Hello,
I'm having a problem updating my current version of core utils to
coreutils-5.2.1-48.1.i386.rpm - taken from the fedora updates page and
I am encountering the following error...
Preparing... ###########################################
[100%]
1:coreutils ###########################################
[100%]
error: unpacking of archive failed on file /bin/ls: cpio: rename failed
- Operat
ion not permitted
I am using fedora 4 on intel platform... The same process failed in the
past when trying to use up2date... There is no version of yum currently
installed on the box...
Has anybody encountered this problem before? Any idea how to resolve?
--
I have since noticed that the owner of the file is not root and is '122' in group '114', is this normal in Fedora 4? I have not changed it from default... I tried to change ownership back to root - but this was not permitted... Any ideas?
--
Best Regards,
Mark Starmer
Last edited by starms; 06-06-2006 at 06:00 AM.
Reason: found more information about problem
error: unpacking of archive failed on file /bin/ls: cpio: rename failed - Operation not permitted
Four chances AFAIK from unlikely to more likely plus the commands to check: partition mounted read-only: "mount|grep ro", extended attribute "immutable" set: "lsattr -d /bin /bin/ls", DAC permissions: "ls -ld /bin /bin/ls".
A fifth chance would be having set a specific SELinux policy, but then you would know that.
If you post any output please post *exact* lines.
the owner of the file is not root and is '122' in group '114'
First of all the indication of showing numerical UID's (unless you specifically used args for that) is a sign there's something amiss with (resolving from) your passwd data. Second utilities in /bin can be owned by other users like mail or rpm, but not /bin/ls. Third 122/114 are above the "regular" wetware UID of 500, which should denote them as lesser-privileged system users. Manual inspection with "getent passwd 122; getent group 114" should show if there even *is* a user/group assigned to that UID and its details.
If unsure I would list network connections and processes "netstat -pan 2>&1>/tmp/netstat.log; ps -axfwwwe 2>&1>/tmp/process.log", then drop to runlevel 1 "telinit 1", (run the ps again and output to another logfile), start a "rpm -Va --noscripts 2>&1|tee /tmp/rpmchk.log &" in the background and start visually checking systems auth data ("less /etc/passwd /etc/shadow": move to next file with ":n"), system logs ("less /etc/syslog.conf" to see which logs are used, usually "messages") and the netstat and ps logs and /tmp/rpmchk.log when it's finished. If you have Rootkit Hunter and/or Chkrootkit installed run those just to make sure. If you didn't install those: don't bother. This all may be overkill but then you at least have some basic idea now where to look for info.
Again, if you post any output please post *exact* lines.
And for the second section, I checked my /etc/passwd file and it doesn't appear that this user actually exists. which is backed up by the getent commands
Code:
# getent passwd 122; getent group 114
also, if I try and change the ownership of the file I get the following: -
Code:
# chown -v root /bin/ls
failed to change ownership of `/bin/ls' to root
chown: changing ownership of `/bin/ls': Operation not permitted
I managed to get the problem sorted... It turned out to be the settings of the file attributes
Very perceptive of you ;-p
Determining how the file got chattr'ed in a dir only writable by the root account user would be interesting (unless you can already contribute it to a certain admin playing around), but because a GNU/Linux system doesn't log changes like this without preparation chances are about nil. If you want to keep tabs you would have to save users shell history (easily and often truncated: use rootsh), regularly run a audit/integrity checker and use RBAC to take a way rights with SELinux or GRSecurity (or to some lesser extent: sct, lcap).
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.