Bug 2229180

Summary:	bzip2: When normal user compress a file with read only access he deletes the original file once compression is done
Product:	[Fedora] Fedora	Reporter:	Ehab <ehab.gassem>
Component:	bzip2	Assignee:	Jakub Martisko <jamartis>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	37	CC:	jamartis, jchaloup, mjw
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2023-08-08 13:00:27 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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