> 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
