Re: [Patch] Trailing spaces in cygcheck -cd or -s output.
Op Wed, 22 Sep 2004 13:54:53 +0200 schreef Corinna Vinschen in [EMAIL PROTECTED]: : On Sep 16 07:26, Bas van Gompel wrote: [dump_setup.cc (dump_setup): Avoid trailing spaces on package-list.] : Thanks for the patch. I've applied the patch plus an additional patch which : adds an `if (check_files)' to simplify the expressions in (now two) printf's. Thanks, that's much more readable. Now one can eliminate a spurious ``strlen'', as well. ChangeLog-entry: 2004-09-23 Bas van Gompel [EMAIL PROTECTED] * dump_setup.cc (dump_setup): Remove unneeded strlen when check_files is not set. Patch: --- src/winsup/utils/dump_setup.cc 22 Sep 2004 11:50:51 - 1.15 +++ src/winsup/utils/dump_setup.cc 23 Sep 2004 05:26:51 - @@ -403,8 +403,8 @@ dump_setup (int verbose, char **argv, bo check_package_files (verbose, packages[i].name) ? OK : Incomplete); else - printf (%-*s %-*s\n, package_len, packages[i].name, - strlen(packages[i].ver), packages[i].ver); + printf (%-*s %s\n, package_len, packages[i].name, + packages[i].ver); fflush(stdout); } L8r, Buzz. -- ) | | ---/ ---/ Yes, this | This message consists of true | I do not -- | | // really is | and false bits entirely.| mail for ) | | //a 72 by 4 +---+ any1 but -- \--| /--- /--- .sigfile. | |perl -pe s.u(z)\1.as.| me. 4^re
Re: dinput.h and ddraw.h from Wine with trivial modifications (fwd)
On Sep 22 15:58, Peter Ekberg wrote: Corinna wrote: On Sep 17 13:39, Peter Ekberg wrote: Hello! This is the ddraw.h and dinput.h files from Wine, with some trivial modification by me to make them work in the cygwin environment. They are Copyright (C) the Wine project according to their headers and under the LGPL. I think it is polite to keep them under LGPL rather than converting to the GPL so that changes can flow freely between the two projects. [...] Doesn't this collide with the public domain-ness of w32api? Well, winsock.h, winsock2.h, ws2tcpip.h, gl.h, glext.h and glu.h are not public domain (according to README.w32api), so I figured that two more files was not a major collision. Not my decision though... Probably Cygwin has no problems as long as these header files are never included in Cygwin code itself. Let's ask the MingW folks. Danny, Earnie, any problem with a header file being LGPL'ed? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:[EMAIL PROTECTED] Red Hat, Inc.
[PATCH] Fake POSIX behaviour in seteuid/setegid
Hi folks,
especially Pierre,
I'm thinking of applying the below patch. The idea is that an application
which has changed real as well as effective id to values different from
the saved (==original) id has no way to restore its old identity.
That's obviously not correct from a Windows NT point of view, but this
is a start to mimic the expected behaviour under POSIX. For example
OpenSSH's sshd calls seteuid/setuid to change to an unprivileged user
and then it calls seteuid and setuid again, to test if it's possible
to revert the identity to root. If so, it exists with error. Same for
the gid. The Cygwin version of OpenSSH currently disables these tests,
but it might be a good idea to fake POSIXy behaviour from a portability
point of view.
Any thoughts appreciated. I'd be interested if there's some serious
reason not to do this at all, or if there's a better way to do this.
One caveat of my patch is that changing from one privileged account to
another privileged account disables changing uids, even though the
second account would also have this right. Perhaps the tests should
be coupled with a check, whether the current effective uid has the
appropriate permissions or not. I'm also suspecting that the gid
test is not far away from a total error in reasoning...
Corinna
* syscalls.cc (seteuid32): Mimic POSIX behaviour. After giving up
real and effective uid, don't allow to change uids again.
(setegid32): Ditto for gids.
Index: syscalls.cc
===
RCS file: /cvs/src/src/winsup/cygwin/syscalls.cc,v
retrieving revision 1.348
diff -p -u -r1.348 syscalls.cc
--- syscalls.cc 17 Sep 2004 09:10:53 - 1.348
+++ syscalls.cc 23 Sep 2004 16:16:56 -
@@ -2004,6 +2004,15 @@ seteuid32 (__uid32_t uid)
return 0;
}
+ /* Mimic POSIX behaviour. After giving up the real uid, don't allow
+ to change uids again. */
+ if (cygheap-user.real_uid != cygheap-user.saved_uid
+ myself-uid != cygheap-user.saved_uid)
+{
+ set_errno (EPERM);
+ return -1;
+}
+
cygsid usersid;
user_groups groups = cygheap-user.groups;
HANDLE ptok, new_token = INVALID_HANDLE_VALUE;
@@ -2184,6 +2193,15 @@ setegid32 (__gid32_t gid)
return 0;
}
+ /* Mimic POSIX behaviour. After giving up the real gid, don't allow
+ to change gids again. */
+ if (cygheap-user.real_gid != cygheap-user.saved_gid
+ myself-gid != cygheap-user.saved_gid)
+{
+ set_errno (EPERM);
+ return -1;
+}
+
user_groups * groups = cygheap-user.groups;
cygsid gsid;
HANDLE ptok;
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader mailto:[EMAIL PROTECTED]
Red Hat, Inc.
Re: More pipe problems (was Re: [Fwd: 1.5.11-1: sftp performance problem])
On Sep 23 12:28, Bob Byrnes wrote: OutboundQuota is just the size of the pipe. How do we know that the cygwin ssh didn't really inherit a huge pipe from the win32-native unison? We don't unless checking the the source code or the strace, I guess. The real trouble here seems to be that WriteQuotaAvailable is so low, which (if that is to be believed) indicates the pipe has almost filled. This seems similar to the sftp problem, which I am still investigating; I haven't made much progress during the past week because I've been busy with other things at work, but I have learned a few new things and I'll try to send another report as soon as I can construct a coherent explanation. Cool with me. As I noted, I didn't care for debugging this issue so far so I also might be off-track. But at least my debugging pointed out where something goes wrong so I hope it was useful nevertheless. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:[EMAIL PROTECTED] Red Hat, Inc.
Re: [PATCH] Fake POSIX behaviour in seteuid/setegid
At 06:25 PM 9/23/2004 +0200, Corinna Vinschen wrote: Hi folks, especially Pierre, I'm thinking of applying the below patch. The idea is that an application which has changed real as well as effective id to values different from the saved (==original) id has no way to restore its old identity. That's obviously not correct from a Windows NT point of view, but this is a start to mimic the expected behaviour under POSIX. For example OpenSSH's sshd calls seteuid/setuid to change to an unprivileged user and then it calls seteuid and setuid again, to test if it's possible to revert the identity to root. If so, it exists with error. Same for the gid. The Cygwin version of OpenSSH currently disables these tests, but it might be a good idea to fake POSIXy behaviour from a portability point of view. Any thoughts appreciated. I'd be interested if there's some serious reason not to do this at all, or if there's a better way to do this. One caveat of my patch is that changing from one privileged account to another privileged account disables changing uids, even though the second account would also have this right. Perhaps the tests should be coupled with a check, whether the current effective uid has the appropriate permissions or not. I'm also suspecting that the gid test is not far away from a total error in reasoning... Corinna, The patch does what you describe. The gid patch does not allow privileged users to change the gids any way they want, which is unusual. What surprised me is that OpenSSH takes the trouble to check if reversion is impossible, although it's the standard POSIX behavior (well, not quite. POSIX mentions appropriate privileges of the process). There must be cases where it can be a problem. I assume it's not risky in Cygwin, because there will soon be an exec that will insure security. Given that there might be issues, I think it's not good practice to mask the real behavior when programs try to find what it is. The more so when it comes to security. I'd rather let the porter look at the issue and decide what's reasonable for a given program on a given platform, as you did. Let me sleep on this! Pierre
