Bug 2229180 - bzip2: When normal user compress a file with read only access he deletes the original file once compression is done
Summary: bzip2: When normal user compress a file with read only access he deletes the ...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: bzip2
Version: 37
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Jakub Martisko
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2023-08-04 14:58 UTC by Ehab
Modified: 2023-08-08 13:00 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2023-08-08 13:00:27 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Ehab 2023-08-04 14:58:32 UTC
Hi everyone,
I noticed this issue today when compressing files owned by root meanwhile having the read access only for group and other (-rw-r--r--. 1 root root).
When compressing using bzip2 -9 file_name
The files gets deleted once the compression is done which is normal if the user running the command owns the file. Still i dont think the user should be able to delete the file without having the permission


Reproducible: Always

Steps to Reproduce:
1. create any file using root user and granting permission 0644
2. as you can read the file with normal user try to compress it using bzip2 -9 file_name
3. the file gets compressed and deleted as the normal behavior of bzip2 how ever write rights are not available for the user whom compressed the file
Actual Results:  
The file which is owned by the root user gets deleted by normal user

Expected Results:  
User should not be able to delete the file

the bzip2 version is 1.0.8, 13-Jul-2019.

Comment 1 Jakub Martisko 2023-08-08 13:00:27 UTC
Hello, 

file deletion is based on the parent directory permissions, not on the permissions of the file itself. Check "RESTRICTED DELETION FLAG OR STICKY BIT"
 section in chmod manpage to achieve the expected behavior. 

The /tmp directory usually has the sticky bit set (you can try the following with rm instead of bzip2):

pwd && ll foo && bzip2 foo; ll foo
/tmp
-rw-r--r-- 1 root root 0 Aug  8 12:27 foo

bzip2: I/O or other error, bailing out.  Possible reason follows.
bzip2: Operation not permitted
	Input file = foo, output file = foo.bz2
-rw-r--r-- 1 root root 0 Aug  8 12:27 foo


On the other hand, directory without the sticky bit:

pwd && ll foo && bzip2 foo && ll foo
/tmp/test
-rw-r--r-- 1 root root 0 Aug  8 12:46 foo
ls: cannot access 'foo': No such file or directory


Note You need to log in before you can comment on or make changes to this bug.