Re: [Chicken-hackers] Ticket 942 - make install uses user's umask
* DG Ward david.w...@zerospace.co.nz [131122 07:03]: Hey guys, I've been working away on fixing the problem described here: http://bugs.call-cc.org/ticket/942 The problem only manifests itself when you install via. sudo. The reason that the issue arose is that no owner was specified for the files being installed. This meant that the owner defaulted to the person who ran the command. That itself may not seem like it should screw up the permissions as they were directly specified (e.g. -m755). The gotcha? Sudo doesn't let issued programs set a umask that's more permissive than that of the invoking user. Explicitly stating the owner as root lets us set the mode to whatever we please :) Changing the userid to root is not a good solution: It works except for local installs, where this trick breaks the install: $ make PLATFORM=linux PREFIX=~/chickentest install [...] install -d -o root -g root /home/ckeen/chickentest/lib install: cannot change owner and permissions of '/home/ckellerm/ckeen/lib': Operation not permitted [...] I don't know if that really is a global problem at all. I have never noticed this on my systems. Which OS are you running? Would it be possible for you to set the -g option in your sudo config? Kind regards, Christian -- In the world, there is nothing more submissive and weak than water. Yet for attacking that which is hard and strong, nothing can surpass it. --- Lao Tzu ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] Ticket 942 - make install uses user's umask
I agree that setting the user-id explicitly isn't the right way to do things, so, I spent some more time playing about. I've found that the problem seemed to be more about the permissions being set on the directories created during installation rather than the files that're being installed within them. Anyway! I've got a new patch for you to play with. All it does in comparison to the original defaults.make is that it uses install to create a directory and specifies only the permissions to use for that new directory - 755. ~K ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] Ticket 942 - make install uses user's umask
On Sat, Nov 23, 2013 at 05:39:51AM +1300, DG Ward wrote: Anyway! I've got a new patch for you to play with. All it does in comparison to the original defaults.make is that it uses install to create a directory and specifies only the permissions to use for that new directory - 755. I think you forgot to attach it :) Cheers, Peter -- http://www.more-magic.net ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] Ticket 942 - make install uses user's umask
On 2013-11-23 07:07, Peter Bex wrote: On Sat, Nov 23, 2013 at 05:39:51AM +1300, DG Ward wrote: Anyway! I've got a new patch for you to play with. All it does in comparison to the original defaults.make is that it uses install to create a directory and specifies only the permissions to use for that new directory - 755. I think you forgot to attach it :) Cheers, Peter D'Oh! Let's try this again! ~K--- chicken-4.8.0.5.orig/defaults.make 2013-03-19 17:27:19.0 + +++ chicken-4.8.0.5.mine/defaults.make 2013-11-23 05:24:01.086197120 + @@ -109,7 +109,7 @@ MAKEDIR_COMMAND ?= -mkdir else INSTALL_PROGRAM ?= install -MAKEDIR_COMMAND ?= mkdir +MAKEDIR_COMMAND ?= install endif POSTINSTALL_STATIC_LIBRARY ?= true POSTINSTALL_PROGRAM ?= true @@ -198,7 +198,7 @@ INSTALL_PROGRAM_STATIC_LIBRARY_OPTIONS ?= -m644 INSTALL_PROGRAM_EXECUTABLE_OPTIONS ?= -m755 INSTALL_PROGRAM_FILE_OPTIONS ?= -m644 -MAKEDIR_COMMAND_OPTIONS ?= -p +MAKEDIR_COMMAND_OPTIONS ?= -d -m755 endif ASSEMBLER_OPTIONS ?= $(C_COMPILER_OPTIONS) ASSEMBLER_OUTPUT_OPTION ?= -o ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
[Chicken-hackers] [PATCH] Fix #765 and a small can of worms related to error handling under Windows
Hi all,
See the attached patch, it kind of speaks for itself.
I don't know why, but looks like Win7 doesn't allow cloning
a handle from the current process and then setting its access
to INHERIT. I guess this is a security measure, but it should
be just fine if we clone it and keep the current permissions
because if *we* aren't allowed to inherit it, there's nothing we
can do about it anyway to make it inheritable for the child.
The error handling in Windows was completely broken; the errmap
loop updated map, but looked at errmap. I've made it a little more
idiomatic, so it's obviously correct. So far the errno isn't
really used anywhere. It looks like this exists only because errno
is foolishly exposed to the user via the posix-error and errno
procedures, and for that to sort-of work (it doesn't), this strange
conversion is being done. Reworking that will be like opening a
whole other can of worms, so I kept it closed for the time being,
at least until 4.9.0 is released.
I think this patch should go into the stability branch.
Cheers,
Peter
--
http://www.more-magic.net
From 6691df7b11bbd79c1e5fbdc201b97327bcf6cb53 Mon Sep 17 00:00:00 2001
From: Peter Bex peter@xs4all.nl
Date: Fri, 22 Nov 2013 20:34:30 +0100
Subject: [PATCH] Fix process under Windows and fix general error handling
under Windows.
- In PROCESS, don't try to mark duplicated descriptors from the parent
process as inheritable; this isn't allowed (and they should already
be inheritable or you can't duplicate them, and we duplicate with
SAME_ACCESS anyway).
- In PROCESS[*], don't try to close handles that haven't been opened.
- When setting the errno for nonexisting error, don't loop endlessly.
- When no error is known, just set it to ENOTSUP (what to do?)
- Add simple regression test for process/process*.
---
NEWS |4 +++-
posixwin.scm | 27 ---
tests/posix-tests.scm | 11 +++
3 files changed, 30 insertions(+), 12 deletions(-)
diff --git a/NEWS b/NEWS
index 2f1e06d..a168975 100644
--- a/NEWS
+++ b/NEWS
@@ -13,7 +13,9 @@
use modules and forgot to require ports but use procedures from it.
- Support has been added for the space-safe R7RS macro delay-force.
- Export file-type from the posix unit (thanks to Alan Post).
- - unsetenv has been fixed on Windows
+ - unsetenv has been fixed on Windows.
+ - The process procedure has been fixed on Windows.
+ - The posix unit will no longer hang upon any error in Windows.
- Platform support
- CHICKEN can now be built on AIX (contributed by Erik Falor)
diff --git a/posixwin.scm b/posixwin.scm
index c5091a5..09f69e3 100644
--- a/posixwin.scm
+++ b/posixwin.scm
@@ -369,15 +369,16 @@ static errmap_t errmap[] =
static void C_fcall
set_errno(DWORD w32err)
{
-errmap_t *map = errmap;
-for (; errmap-win32; ++map)
+errmap_t *map;
+for (map = errmap; map-win32; ++map)
{
- if (errmap-win32 == w32err)
+ if (map-win32 == w32err)
{
- errno = errmap-libc;
+ errno = map-libc;
return;
}
}
+errno = ENOSYS; /* For lack of anything better */
}
static int C_fcall
@@ -785,15 +786,13 @@ C_process(const char * app, const char * cmdlin, const
char ** env,
if (modes[i]=='r') { child_io_handles[i]=a; parent_end=b; }
else { parent_end=a; child_io_handles[i]=b; }
success = (io_fds[i] = _open_osfhandle((C_word)parent_end,0))
= 0;
+/* Make new handle inheritable */
+ if (success)
+ success = SetHandleInformation(child_io_handles[i],
HANDLE_FLAG_INHERIT, -1);
}
}
}
-/** make handles inheritable */
-
-for (i=0; i3 success; ++i)
- success = SetHandleInformation(child_io_handles[i],
HANDLE_FLAG_INHERIT, -1);
-
#if 0 /* Requires a sorted list by key! */
/** create environment block if necessary /
@@ -853,7 +852,10 @@ C_process(const char * app, const char * cmdlin, const
char ** env,
/** cleanup return */
/* parent must close child end */
-for (i=0; i3; ++i) CloseHandle(child_io_handles[i]);
+for (i=0; i3; ++i) {
+ if (child_io_handles[i] != NULL)
+ CloseHandle(child_io_handles[i]);
+}
if (success)
{
@@ -864,7 +866,10 @@ C_process(const char * app, const char * cmdlin, const
char ** env,
}
else
{
- for (i=0; i3; ++i) _close(io_fds[i]);
+ for (i=0; i3; ++i) {
+ if (io_fds[i] != -1)
+ _close(io_fds[i]);
+ }
}
return success;
diff --git a/tests/posix-tests.scm b/tests/posix-tests.scm
index f227397..4459e36 100644
--- a/tests/posix-tests.scm
+++ b/tests/posix-tests.scm
@@ -32,6 +32,17 @@
(assert-error (process-execute false '(1 123\x00456)))
(assert-error (process-execute false '(123\x00456) '(foo\x00bar
blabla) '(lalala
Re: [Chicken-hackers] [PATCH] Fix #765 and a small can of worms related to error handling under Windows
Can you confirm it works under XP as well? If so I'll apply it to stability. Jim On Nov 22, 2013, at 2:43 PM, Peter Bex peter@xs4all.nl wrote: Hi all, See the attached patch, it kind of speaks for itself. I don't know why, but looks like Win7 doesn't allow cloning a handle from the current process and then setting its access to INHERIT. I guess this is a security measure, but it should be just fine if we clone it and keep the current permissions because if *we* aren't allowed to inherit it, there's nothing we can do about it anyway to make it inheritable for the child. The error handling in Windows was completely broken; the errmap loop updated map, but looked at errmap. I've made it a little more idiomatic, so it's obviously correct. So far the errno isn't really used anywhere. It looks like this exists only because errno is foolishly exposed to the user via the posix-error and errno procedures, and for that to sort-of work (it doesn't), this strange conversion is being done. Reworking that will be like opening a whole other can of worms, so I kept it closed for the time being, at least until 4.9.0 is released. I think this patch should go into the stability branch. Cheers, Peter -- http://www.more-magic.net 0001-Fix-process-under-Windows-and-fix-general-error-hand.patch___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] Fix nonblocking socket behaviour on Windows
On Nov 20, 2013, at 4:20 PM, Peter Bex peter@xs4all.nl wrote: Hi all, Due to Shanmuhanathan's report I looked into Spiffy on Windows, and found out that multithreaded socket handling is completely broken there. Sockets are marked as nonblocking in tcp.scm, but that's done through fcntl() which is #defined as a no-op on Windows (because Windows has no fcntl() at all), so this could never have worked in the first place. I found some notes in the Windows documentation about some select()-like procedure automatically marking any sockets you pass to it as nonblocking, so perhaps this may have obscured this problem in the past if somehow a thread yielded before reading from such a socket. Attached is a patch which enables the marking of sockets as nonblocking for Windows. This should definitely go into the stability branch! Agreed, again as long as it works on XP, or at least doesn't break XP. Jim ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
