sequence of chmod and chown in unrestricted chown environment

[Vladimir Marek]

Hi,

When gzip creates an archive, it tries to retain owner and permissions
of original file. It does this by chown and chmod sequence here:

http://git.savannah.gnu.org/gitweb/?p=gzip.git;a=blob;f=gzip.c;h=93cc7384ff3959664807e7dad470fe01f4c4f99c;hb=HEAD#l1737

Firs 'chown' is executed, second 'chmod'. The problem is, that if you
chown the file first, you may loose an access to it to run the chmod
later. Similar issue was already reported here for hpux

http://lists.gnu.org/archive/html/bug-gzip/2007-06/msg00002.html

The reasoning was that

"The problem is that on many hosts, if you chown a file there is
a side effect that chmods it as well.  So you must chown before
chmoding."

and

"On most systems, if you have enough privileges to chown a file, you
can also chmod it afterwards, so it's not a problem."

On solaris you can mount given filesystem with norstchown parameter
which gives the owner of the file the ability to chown the file to
someone else.

I am looking on how to support gzip on "chown un-restricted"
filesystems. I have several possibilities in mind, but since we would
like to be able to have the patch in the upstream gzip, I would like to
hear your opinions.

a) change chown/chomd sequence in gzip.c

http://git.savannah.gnu.org/gitweb/?p=gzip.git;a=commitdiff;h=3477834ce69a74cb84d6efccd22716475cc506f3

b) make the order of commands (chmod/chown) configurable option via
'configure' script

c) make the order of commands different for solaris (autodetected in
configure)

d) make the order of commands switchable by an command line option / 
environment variable

e) do not modify gzip to support unrestricted chown environments



ad a)
 - That's the simplest option, but I don't like it very much. You had
   some concerns when you made the change in the first place ...
ad b) and c)
 - Booth looks appealing to me

ad d)
 - That seems to me to be too much of an hassle and I don't believe why
   anyone would want to revert the sequence back to current state on
   Solaris.

ad e)
 - Not a preferred solution to me :)


Also it might be seen that setting unrestricted chown is a security
issue, but in reality it's not that hot, as you can set this option only
for specific filesystem to support your users.


Example of an session showing the problem on Solaris:

# Become superuser
$ su - root

# Create new filesystem for testing
$ mkfile 10m /var/tmp/filesystem
$ lofiadm -a /var/tmp/filesystem
$ newfs /dev/lofi/1

# Mount the filesystem with norstchown option (to be able to chown a
# file so that it belongs to different user)
$ mkdir /mount
$ mount -o norstchown /dev/lofi/1 /mount 
$ chmod 777 /mount

# Create file belonging to paul
$ cd /mount
$ touch file
$ chown paul file
$ chmod 640 file

$ ls -l file
-rw-r-----   1 paul   staff          0 Jul  8 12:14 file


# now become bob and gzip the file
$ su - bob
$ cd /mount
$ truss -t open,fchmod,fchown gzip file
open("/var/ld/64/ld.config", O_RDONLY)          Err#2 ENOENT
open("/lib/64/libc.so.1", O_RDONLY)             = 3
open("/lib/64/libthread.so.1", O_RDONLY)        = 3
open("file", O_RDONLY|O_NONBLOCK|O_NOCTTY|O_NOFOLLOW) = 3
open("file.gz", O_WRONLY|O_CREAT|O_EXCL, 0600)  = 4
fchown(4, 157350, 10)                           = 0
fchmod(4, 0640)                                 Err#1 EPERM [file_owner]
gzip: file.gz: Not owner

$ ls -l file*
-rw-------   1 paul   staff         25 Jul  8 12:14 file.gz


As seen, the command failed since 
 - the temporary gz file was created with permissions 600 (user bob)
   - defined by #define RW_USER (S_IRUSR | S_IWUSR) in gzip.c
 - then the file was chowned to user paul
 - then we haven't had enough permissions to chmod it to 640


Thank you
-- 
        Vlad