Marco Colombo wrote: > See above. Umask is useful only if: > * you know nothing in the Makefile changes the permissions when > executing make install; > * you know nothing in the %install section of the spec file > changes permissions either. Setting umask sets the *default*. If something overrides the default then I have to assume at the first level that this override is being done for a reason. That does not invalidate the usefulness of having a default value. If something in the makefile is setting permissions that may be just perfectly fine. chmod 0600 somefile That is fine. chmod 04755 somefile That is bad. If I saw that in a makefile I would have to modify it to correct that behavior. Fortunately that is very rare and only from inexperienced rpm developers. If something like that were in a production rpm from a distro you would be justified in filing a bug against the package to get it fixed. Fortunately the comman case is the typical GNU automake generated makefile and those are generally well behaved. But sometimes developers do get a little over-enthusiastic and make mistakes. In any case, I always browse the files I am going to package and look to see what is happening there. I *always* look at the rpm package with 'rpm -qplv' to inspect the contents of the resulting rpm file. People are trusting you as the packager to know what you are distributing. > If you build only packages you wrote from .spec you wrote, that might be > the case. If you're building random rpms, you can't trust the Makefile > and the %install script. If you are executing random scripts and Makefils from untrusted sources then there are many problems to which you are exposing yourself. > Some people like, with reasons, to set their permissions right in > the buildroot. Using chmod in general is not the issue. If someone sets 0755 or 0600 or some such there is no problem. I think you have latched onto using chmod to create set uid files. I agree that is bad. But that is also very rare. And if you are doing that on a hostile system then that is bad no matter if you try to hide it in a subdirectory somewhere or not. In which case there is no difference between building in /var/tmp/my-restricted-dir or if you are buiding in ~/my-restricted-dir. I am building on my private system where no one else has any access. So even if a file were created that were suid to me I know it cannot be used against me because no one else has access to the system. But I generally won't package something that I have not looked at in at least some detail. But if you are building in a hostile environment well then you have to take more care. That is all there is to it. > The whole point is that the buildroot may stay there for days. What > about a suid executable owned by _you_ and executable by all? The image is normally deleted if the build is successful. So it usually won't hang around longer than the build time. If there is a failure then the corpse is left for autopsy to determine the problem. But at that point you would also see the suid file and would probably do something about that as soon as possible. If you are debugging the build problem you will eventually get to a successful build and the image area will be removed. If you fire off a build of a rpm spec file from an untrusted source that fails and the spec file is bad and creates a suid file and then you walk off and leave it behind then there are so many things going wrong there that I don't know where to begin. Hopefully we are just talking hypothetical situations. Because I think most people use common sense and avoid these problems. Bob
