Bugzilla – Bug 157814
non-executable files in .../bin/ directories of various packages
Last modified: 2008-05-12 16:31:38 UTC
I just grepped ARCHIVES.gz from today's Factory tree for non-executable files in bin/ or sbin/ directories [1]. I found that SuSEconfig.scim is not executable, but all other SuSEconfig.* modules are. ./inst-source/suse/i586/scim-1.4.4-11.i586.rpm: -rw-r--r-- 1 root root 2451 Mar 12 05:09 /sbin/conf.d/SuSEconfig.scim (same result for other archs) Please fix the permissions. [1] zgrep "rpm:[ ]*-..-.*/s\?bin/" ARCHIVES.gz | grep -v debuginfo There are much more results, but unfortunately there are lots of false alerts also (like /sbin/init.d.README) - so someone will have to check that list manually :-/ - any volunteers?
Mike: can you fix the scim package ? (and then we have to find someone to take care of the list)
Fixed or SCIM: ------------------------------------------------------------------- Tue Mar 14 15:42:14 CET 2006 - mfabian@suse.de - Bugzilla #157814: make SuSEconfig.scim executable. ------------------------------------------------------------------- Reassigning to ro@suse.de.
Michael, can you go through the list and open bug reports for each separate issue?
Please save the list of "false alerts" somewhere - it can be used for more automatic tests ("<above command> | grep -vf false-alerts.txt") in the future...
just found in /usr/bin: -rw-r--r-- [...] vlevel-bin -> package ladspa-1.12.code10-6 -rw-r--r-- [...] pygtk-demo -> package python-gtk-2.8.2-11 Both look as they should be executable (vlevel-bin is a ELF binary, pygtk-demo is a python script)
Takashi, Jan, please look at #6.
ladspa package is fixed now.
fixed in python-gtk as well
Christian, can you help solving these issues here? Unfortunately I don't have the time right now.
OK, I'll try (as time permits) - but I guess I will need some help because there are lots of files from which I don't know if they should be executable or not. Therefore package maintainers will see this bug in needinfo to them ;-)
Finally found some time to continue this bugreport ;-) ./inst-source1/suse/i586/gtk-sharp-gapi-1.0.10-51.i586.rpm: -rw-r--r-- /usr/bin/gapi-fixup.exe -rw-r--r-- /usr/bin/gapi_codegen.exe ./inst-source1/suse/i586/gconf-sharp-1.0.10-51.i586.rpm: -rw-r--r-- /usr/bin/gconfsharp-schemagen.exe Files in /usr/bin/ should be executable... (Please remove NEEDINFO state when you have fixed it.)
The *.exe files don't need to be executable. There are shell wrappers for each of those files to be called with /usr/bin/mono. It wouldn't hurt for them to be executable, but there is not point in doing so, from Mono's point of view.
Wade, why are those files in /usr/bin if they are not executable? Either they belong to /usr/bin and have to be executable - or they can live somewhere else.
Just for the records: These .exe's are from gtk-sharp1. gtk-sharp2 is since the beginning fixed to have them in /usr/lib, without execute permissions (which is the technically correct solution). This has never been done for gtk-sharp1, not even in the latest upstream version. Making the files executable is wrong (since SUSE doesn't even load binfmt by default which would be necessary for Mono assemblies to work without a shell wrapper, the execute bit would be useless).
I'll do some rpm install step munging to handle these files as gtk-sharp2 does (put .exe files in /usr/lib/gtk-sharp). ... -> Submitted.
The *.exe files in gtk-sharp-gapi and gconf-sharp are now (10.2 final) below /usr/lib. Wane, thanks for fixing this - and merry X-mas!
Next round after some delay ;-) From today's factory tree: # rpm -qvpl nagios-2.9-30.i586.rpm |grep bin -rwxrwxr-x 1 root root 22184 Aug 6 23:41 /usr/sbin/convertcfg -rwxrwxr-x 1 root root 18296 Aug 6 23:41 /usr/sbin/mini_epn -rwxrwxr-- 1 root root 460420 Aug 6 23:41 /usr/sbin/nagios -rwxrwxr-- 1 root root 28496 Aug 6 23:41 /usr/sbin/nagiostats -rwxrwxr-x 1 root root 18312 Aug 6 23:41 /usr/sbin/new_mini_epn -rw-rw-r-- 1 root root 31415 Aug 6 23:41 /usr/sbin/p1.pl lrwxrwxrwx 1 root root 18 Aug 6 23:41 /usr/sbin/rcnagios -> /etc/init.d/nagios -> Is there a special reason why /usr/sbin/p1.pl is not executable? Please make it executable or move it to another directory.
Christian, The info provider was empty. Can you re-set the needinfo to the correct person.
*argh* - seems not everybody shares his alias @suse.de and @novell.com I hope I have the correct person now ;-) - Thomas, in case you are not the nagios maintainer, please move the bug to the correct person.
Changed it. Olaf, see #18.
fixed nagios
I had hoped that I can close this bug, but instead I have to move it forward to 11.0 beta2... Cron sends me mails saying "/bin/sh: /usr/bin/reportgen.pl: Permission denied". This is the AppArmor reporting cronjob (already setup on 10.3 BTW). Reason of the problem: ./inst-source1/suse/noarch/yast2-apparmor-2.16.1-17.noarch.rpm: -rw-r--r-- 1 root root 17693 Jan 15 10:32 /usr/bin/reportgen.pl -> Please make reportgen.pl executable (again). BTW: Katarina, am I right that you are the current maintainer of yast2-apparmor? (guess based on changelog) If not, please move the needinfo to the correct person ;-)
> BTW: Katarina, am I right that you are the current maintainer of > yast2-apparmor? (guess based on changelog) Unfortunately, you're right, I maintain y2-aa now :) Checked permissions in SLE10 SP1, reportgen.pl had rwxr-xr-x back then. It is probably regression caused by migrating yast2-apparmor into yast subversion and adapting it to standard yast autotools based build.
(In reply to comment #24 from Katarina Machalkova) > Unfortunately, you're right, I maintain y2-aa now :) That's really bad luck for you *g* - I just reassigned some bugs regarding "yast $apparmor_module does not understand the help option" to you ;-) (bug 269891, bug 269898, bugs 269002 - 269906)
This should be fixed in y2-apparmor 2.16.3, dunno if it will reach b3, though