HEADSUP maintainers: Packages install scripts without execute permissions
[Wrong list. Resent to cygwin-apps] Hi, Here's the problem: If you exec shell scripts, they should only be run if the user trying to run the script has execute permissions on the script. This requires to check for executability in Cygwin, but as of today, such a check isn't performed in Cygwin. I have the patch for this ready, but I found that it would potentially break a couple of packages which have not set execute permissions on some of their script files. As you should know by now, setup for Cygwin 1.7 will set POSIX file permissions for the files extracted from the tar archives. That means, all scripts which don't have execute permissions set, will also not have execute permissions set after the user installed them. That's bad. So I created a list of packages which install scripts into /etc/preremove, /etc/postinstall, and /usr/bin without setting execute permissions on them. Please guys, fix the permissions ASAP. Corinna Vinschen: robots: etc/postinstall/robots.sh Reini Urban: perl: usr/bin/cpan5.10.0 usr/bin/shasum5.10.0 Christian Franke: ddrescue: etc/postinstall/ddrescue.sh Jari Aalto: colorgcc: etc/postinstall/colorgcc.sh joe: etc/postinstall/joe-manifest.lst Frank Seelisch: singular-icons: etc/postinstall/singular-icons.sh Dave Korn: gcc-core: etc/postinstall/gcc.sh etc/preremove/gcc.sh gcc-gnat: etc/postinstall/gcc-gnat.sh etc/preremove/gcc-gnat.sh gcc-gdc: etc/postinstall/gcc-gdc.sh etc/preremove/gcc-gdc.sh gcc-gpc: etc/postinstall/gcc-gpc.sh etc/preremove/gcc-gpc.sh gcc-g++: etc/postinstall/gcc-g++.sh etc/preremove/gcc-g++.sh gcc-g77: etc/postinstall/gcc-g77.sh etc/preremove/gcc-g77.sh gcc-java: etc/postinstall/gcc-java.sh etc/preremove/gcc-java.sh Yaakov S: perl-extutils-pkgconfig: etc/postinstall/perl-ExtUtils-Pk libgnome2:etc/preremove/libgnome2.sh gnome-vfs:etc/preremove/gnome-vfs2.sh ilibIDL: etc/postinstall/libIDL.sh libIDL2: etc/postinstall/libIDL2.sh Btw., DLLs should also be executable, otherwise applications will fail to start. I found one of them: glib: usr/bin/cyggmodule-1-2-0.dll Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: HEADSUP maintainers: Packages install scripts without execute permissions
On 6/22/2009 9:12 AM, Corinna Vinschen wrote: Here's the problem: If you exec shell scripts, they should only be run if the user trying to run the script has execute permissions on the script. This requires to check for executability in Cygwin, but as of today, such a check isn't performed in Cygwin. I have the patch for this ready, but I found that it would potentially break a couple of packages which have not set execute permissions on some of their script files. As you should know by now, setup for Cygwin 1.7 will set POSIX file permissions for the files extracted from the tar archives. That means, all scripts which don't have execute permissions set, will also not have execute permissions set after the user installed them. That's bad. So I created a list of packages which install scripts into /etc/preremove, /etc/postinstall, and /usr/bin without setting execute permissions on them. Please guys, fix the permissions ASAP. Users who have existing preremove scripts without execute permissions will still have problems if you change setup.exe to check for this, won't they? Ken
Re: HEADSUP maintainers: Packages install scripts without execute permissions
On Jun 22 09:45, Ken Brown wrote: On 6/22/2009 9:12 AM, Corinna Vinschen wrote: Here's the problem: If you exec shell scripts, they should only be run if the user trying to run the script has execute permissions on the script. This requires to check for executability in Cygwin, but as of today, such a check isn't performed in Cygwin. I have the patch for this ready, but I found that it would potentially break a couple of packages which have not set execute permissions on some of their script files. As you should know by now, setup for Cygwin 1.7 will set POSIX file permissions for the files extracted from the tar archives. That means, all scripts which don't have execute permissions set, will also not have execute permissions set after the user installed them. That's bad. So I created a list of packages which install scripts into /etc/preremove, /etc/postinstall, and /usr/bin without setting execute permissions on them. Please guys, fix the permissions ASAP. Users who have existing preremove scripts without execute permissions will still have problems if you change setup.exe to check for this, won't they? If the affected packages are replaced before we install a new Cygwin DLL, which correctly checks for execute permissions, the preremove scripts would be replaced with the ones with correct permissions before the problem actually starts to become visible. I don't understand how you suggest to change setup.exe. In theory, it could change permissions of scripts in /etc/preremove and /etc/postinstall on the fly while installing them, as it already does for *.exe files. It could do the same also for .dll files, btw. Is that what you mean? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: HEADSUP maintainers: Packages install scripts without execute permissions
On Mon, Jun 22, 2009 at 09:45:12AM -0400, Ken Brown wrote: On 6/22/2009 9:12 AM, Corinna Vinschen wrote: Here's the problem: If you exec shell scripts, they should only be run if the user trying to run the script has execute permissions on the script. This requires to check for executability in Cygwin, but as of today, such a check isn't performed in Cygwin. I have the patch for this ready, but I found that it would potentially break a couple of packages which have not set execute permissions on some of their script files. As you should know by now, setup for Cygwin 1.7 will set POSIX file permissions for the files extracted from the tar archives. That means, all scripts which don't have execute permissions set, will also not have execute permissions set after the user installed them. That's bad. So I created a list of packages which install scripts into /etc/preremove, /etc/postinstall, and /usr/bin without setting execute permissions on them. Please guys, fix the permissions ASAP. Users who have existing preremove scripts without execute permissions will still have problems if you change setup.exe to check for this, won't they? Doesn't setup.exe invoke preremove/postinstall shell scripts via bash foo.sh? You don't need exec permissions for that. cgf
Re: HEADSUP maintainers: Packages install scripts without execute ?permissions
On Jun 22 16:09, Corinna Vinschen wrote: On Jun 22 13:58, Eric Blake wrote: For that matter, are there any postinstall scripts currently relying on a different interpreter? If not, then I'm in favor of the idea of changing setup.exe to be immune to the execute bit on postinstall scripts, at the expense of making postinstall scripts locked into bash (at least, as the initial interpreter). There can be only *.bat and *.sh files in /etc/postinstall and /etc/preremove. *.bat files are started via `cmd /c file' and *.sh files are started via `bash --norc --noprofile -c file'. So we sort of require a script to be a sh/bash script anyway right now. Admittedly, I did not actually *look* into all postinstall/preremove scripts in the distro. I just checked the entire 1.7 distro and here's the result: We have not a single package left which uses a .bat file in postinstall or in preremove. That's great, IMHO. And, AFAICS, all of the *.sh fiels are actually some variation of sh/ash/bash script. So I assume it's safe to remove the -c from setup's script starter method. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: HEADSUP maintainers: Packages install scripts without execute permissions
On 6/22/2009 10:04 AM, Corinna Vinschen wrote: If the affected packages are replaced before we install a new Cygwin DLL, which correctly checks for execute permissions, the preremove scripts would be replaced with the ones with correct permissions before the problem actually starts to become visible. Ah, that's the part I was missing. Sorry for the noise. Ken
