Gzip compressed file ownership and permissions

gzippermissionsunix

I'm trying to find out how gzipping a file changes its permissions.
The gzip manual (man gzip) says:

Whenever possible, each file is
replaced by one with the extension
.gz, while keeping the same ownership
modes, access and modification times.

Now, I have a file 'myfile.txt' whose owner is me (myuser). When I gzip this file as another user (that user (say 'otheruser') has read and write permissions in this directory and file), the owner of the gzip file becomes this otheruser. That is, whoever gzip's the file becomes the owner of the .gz file.

Also, whoever gunzip's this file becomes the owner of the uncompressed file. Does this mean gzip does nothing at all about ownerships? If so, what does the above sentence in the manual page mean?

I don't believe the 'Whenever possible' clause might be a problem here since I'm in Unix (Solaris) where permissions retention is (AFAIK) possible.

A related question: if a user has read permission on a .gz file, is it still possible that he cannot read the contents of the file? Does gzip maintain a separate set of permissions 'within' the archive which can limit access? This does not seem probable, but I'd like to be sure.

I need to write code depending on the behaviour of gzip, so finding out the exact behaviour is important for me. Any help would be appreciated.

Thanks.

Best Answer

Changing file ownership can only be done by root. Ordinary user_a simply cannot create a file owned by ordinary user_b, whether file creation is done by gzipping or by gunzipping. If you need to preserve ownership, unzip as root.

Related Solutions

Linux – Change file ownership during write operation

Afaik, POSIX 1003.1 requires only fopen to return an [EACCES] error on insufficient privileges. Subsequent operations like fputc might return a [EBADF] bad file descriptor error, but i don't think that is meant to cover permission changes while the file is open.

Years ago, i worked in a company where we had our AIX servers set up so that they used that property to make logfiles more secure. When a service started, root would touch /var/log/service.log, then chown it to serveruser:servergroup, su - start the service (it would open the file in append mode), and then chown the file back to root. Consequently, the service could append to its own logfile, but not delete or overwrite it, so if an attacker managed to compromise the service he couldn't tamper with past log entries.

A similar trick can be used for temporary files: open the file, then remove it. The directory entry is gone and the file is invisible, but since the file handle is still open, the inode is still there. Once you close the file, the link count goes to zero, and the OS reclaims the disk space.

Linux – How to two users be the owners of a file

In the traditional Unix file permission system that's not possible: a file has only a single owner. You could create a group containing just the two users that should have access and make that the owning group of the file (and give the desired permissions to that group). This approach has some administrative overhead, however (not every user can create a group and place other users in it).

Many (most) modern filesystems support ACLs, however and they aren't too hard to use. If you want to use POSIX ACLs to give another user read (r) and write (w) permissions then you can use this command:

setfacl -m user:mymain:rw file.ini

Two caveats:

The necessary tools aren't always installed. On Ubuntu/Debian they are found in the acl package (sudo apt-get install acl)
Even if the filesystem used supports ACLs, it might be that your local filesystem is mounted without support for ACLs. In that case you need to modify the mount parameters to enable it (for ext4, for example, that simply means appending ,acl to the mount options in /etc/fstab).

Related Question