bug#15672: Re: bug#15672: Sequence of chmod and chown - patch

[Vladimir Marek]

> Doesn't this patch introduce a security hole into the
> Solaris port of gzip?
> 
> If gzip chmods the output file before chowning it,
> the output file may be (say) group-readable to the
> current user's group, even though the intent is
> that the file be group-readable only to the intended
> user's group.  This will allow someone to read the file
> who shouldn't be able to read the file, if they open
> the file between the chmod and the chown.

I see, that didn't cross my mind.


> Instead, how about the following idea.  On Solaris, if
> a process discovers that it has the right to chown
> but it cannot chmod other people's files, then it
> relinquishes the right to chown.  That way, the chown
> will fail (just as it does on GNU systems) and gzip
> will behave on Solaris as it does elsewhere, and this
> security hole will be closed.

I understand what you say, still I think that there might be a way how
to do chmod/chown better. And it's not just Solaris. For example my
Linux has _PC_CHOWN_RESTRICTED described in pathconf(3). I have no idea
whether this option is in fact implemented or not, but it does not seem
to be Solaris only.

How about

 - create the new file with perms 600
 - use chown to set the proper group, but not owner (yet)
 - use chmod to set perms
 - use chown to set proper file owner

That should stop the race between chmod and chown and at the same time
it should work for both normal and 'norstchown/file_chown_self'
conditions.

-- 
        Vlad