Hi,
I have a python-pygit2 review, in this review the reviewer asked me to change the perms of the .so files from 755 to 644. In fact I've done this for many other packages, but I want to ask if this is really needed?
I've asked pygit2 upstream at: https://github.com/libgit2/pygit2/issues/259
They said that pillow has 755 perms so files, too. So I ran:
[rpmaker@fab PIL]$ ls -al|grep .so -rwxr-xr-x. 1 root root 15768 8月 29 19:30 _imagingcms.so -rwxr-xr-x. 1 root root 15976 8月 29 19:30 _imagingft.so -rwxr-xr-x. 1 root root 18732 8月 29 19:30 _imagingmath.so -rwxr-xr-x. 1 root root 290820 8月 29 19:30 _imaging.so -rwxr-xr-x. 1 root root 10524 8月 29 19:30 _imagingtk.so -rwxr-xr-x. 1 root root 10548 8月 29 19:30 _webp.so
Well seems they are 755, too.
What should I do now?
Thanks in advance.
Yours sincerely, Christopher Meng
Always playing in Fedora Project
On Tue, 10 Sep 2013 18:01:09 +0800, Christopher Meng wrote:
Hi,
I have a python-pygit2 review, in this review the reviewer asked me to change the perms of the .so files from 755 to 644. In fact I've done this for many other packages, but I want to ask if this is really needed?
No, the reviewer is mistaken. It would be a packaging bug, and you will need to fix your "many other packages", too.
1) The shared libs don't get stripped, if they are not executable. 2) The -debuginfo package generation doesn't work either, if the libs are not executable.
On Tue, Sep 10, 2013 at 6:13 PM, Michael Schwendt mschwendt@gmail.com wrote:
No, the reviewer is mistaken. It would be a packaging bug, and you will need to fix your "many other packages", too.
- The shared libs don't get stripped, if they are not executable.
- The -debuginfo package generation doesn't work either, if the libs are not executable.
Thanks, I was just thinking about the debuginfo after sending this email(it made me confused for a long time), your hint is right!
Michael Schwendt wrote, at 09/10/2013 07:13 PM +9:00:
On Tue, 10 Sep 2013 18:01:09 +0800, Christopher Meng wrote:
Hi,
I have a python-pygit2 review, in this review the reviewer asked me to change the perms of the .so files from 755 to 644. In fact I've done this for many other packages, but I want to ask if this is really needed?
No, the reviewer is mistaken. It would be a packaging bug, and you will need to fix your "many other packages", too.
- The shared libs don't get stripped, if they are not executable.
- The -debuginfo package generation doesn't work either, if the libs are not executable.
Well, I am so long wondering about this. Actually creating debuginfo, stripping shared libs and making the shared libs non executable can be accomplished by using %attr, i.e. - At %install, install the shared libs with 0755 as before - On %files, explicitly mark the files with %attr(0644,root,root)
http://koji.fedoraproject.org/koji/taskinfo?taskID=5923317
Some other distros makes non-executable shared libs 0644 permission. Is %attr approach for this case allowed / preferable / discouraged ?
Regards, Mamoru
On Thu, 12 Sep 2013 00:29:58 +0900, Mamoru TASAKA wrote:
Well, I am so long wondering about this. Actually creating debuginfo, stripping shared libs and making the shared libs non executable can be accomplished by using %attr, i.e.
- At %install, install the shared libs with 0755 as before
- On %files, explicitly mark the files with %attr(0644,root,root)
http://koji.fedoraproject.org/koji/taskinfo?taskID=5923317
Some other distros makes non-executable shared libs 0644 permission. Is %attr approach for this case allowed / preferable / discouraged ?
It is widely accepted practice to limit %attr usage to really special permissions (such as setuid, setgid) and ownership (non-root user and/or group), so where that is done in a spec file, it sticks out. In packages with many files, overusing %attr would decrease readability even when using spec syntax-highlighting. Ordinary file permissions should get fixed in %install and upstream.
Is it guaranteed that %attr will set the permission _after_ debuginfo generation?
AFAIK, the only thing that wants +x on these libs is the debuginfo generator, and IIRC there's support already for flipping a flag and making it work with non-executables, too.
ldd still warns about non-executable libs. And the build tools are not specific to Fedora/Linux, so they will likely keep making .so files +x.
How many of the libs contain special code that can be run? I don't want to imagine a large configure script running a lib for some version check or feature list. Would packagers need to check every lib for whether it may be run or not?
Hi:
Michael Schwendt wrote, at 09/12/2013 07:47 PM +9:00:
On Thu, 12 Sep 2013 00:29:58 +0900, Mamoru TASAKA wrote:
Well, I am so long wondering about this. Actually creating debuginfo, stripping shared libs and making the shared libs non executable can be accomplished by using %attr, i.e.
- At %install, install the shared libs with 0755 as before
- On %files, explicitly mark the files with %attr(0644,root,root)
http://koji.fedoraproject.org/koji/taskinfo?taskID=5923317
Some other distros makes non-executable shared libs 0644 permission. Is %attr approach for this case allowed / preferable / discouraged ?
It is widely accepted practice to limit %attr usage to really special permissions (such as setuid, setgid) and ownership (non-root user and/or group), so where that is done in a spec file, it sticks out. In packages with many files, overusing %attr would decrease readability even when using spec syntax-highlighting. Ordinary file permissions should get fixed in %install and upstream.
Is it guaranteed that %attr will set the permission _after_ debuginfo generation?
Yes, because debuginfo generation is done at %__spec_install_post, and %check follows after that.
AFAIK, the only thing that wants +x on these libs is the debuginfo generator, and IIRC there's support already for flipping a flag and making it work with non-executables, too.
Well, currently I don't know that.
ldd still warns about non-executable libs. And the build tools are not specific to Fedora/Linux, so they will likely keep making .so files +x.
(While I don't know well about Debian) it seems at least Debian makes .so files 0644 for most cases (and perhaps also Ubuntu), ref:
https://lists.fedoraproject.org/pipermail/devel/2011-March/149822.html https://lists.fedoraproject.org/pipermail/devel/2011-March/149857.html
How many of the libs contain special code that can be run?
Perhaps libc, libpthread and some very special exceptions
I don't want to imagine a large configure script running a lib for some version check or feature list. Would packagers need to check every lib for whether it may be run or not?
So I think for most cases they do not (need not) run, and only quite a few cases should be concerned.
Regards, Mamoru
Mamoru TASAKA wrote, at 09/12/2013 11:51 PM +9:00:
I don't want to imagine a large configure script running a lib for some version check or feature list. Would packagers need to check every lib for whether it may be run or not?
So I think for most cases they do not (need not) run, and only quite a few cases should be concerned.
Well, here only "a few" (not "quite a few") cases should be concerned.
Regards, Mamoru
2013/9/10 Christopher Meng cickumqt@gmail.com:
Hi,
I have a python-pygit2 review, in this review the reviewer asked me to change the perms of the .so files from 755 to 644. In fact I've done this for many other packages, but I want to ask if this is really needed?
You shouldn't change permissions on so-files. Otherwise RPM debuginfo- and dependency-generators won't process them. At least that was in the earlier versions of rpmbuild.
Peter Lemenkov wrote, at 09/10/2013 07:24 PM +9:00:
2013/9/10 Christopher Meng cickumqt@gmail.com:
Hi,
I have a python-pygit2 review, in this review the reviewer asked me to change the perms of the .so files from 755 to 644. In fact I've done this for many other packages, but I want to ask if this is really needed?
You shouldn't change permissions on so-files. Otherwise RPM debuginfo- and dependency-generators won't process them. At least that was in the earlier versions of rpmbuild.
For debuginfo issue, please check my previous mail. For dependency generation, actually in many cases we want to filter it out.
Regards, Mamoru
packaging@lists.fedoraproject.org
-
Christopher Meng -
Mamoru TASAKA -
Michael Schwendt -
Peter Lemenkov