[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
sequence of chmod and chown in unrestricted chown environment
From: |
Vladimir Marek |
Subject: |
sequence of chmod and chown in unrestricted chown environment |
Date: |
Mon, 8 Jul 2013 16:36:50 +0200 |
User-agent: |
Mutt/ (2012-12-30) |
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
- sequence of chmod and chown in unrestricted chown environment,
Vladimir Marek <=