On Thu, Jan 31, 2002 at 10:07:36PM -0500, Pierre A. Humblet wrote:
I saw that, but my editor is not setup for your tab settings and for
your C indent style. You probably wouldn't like it if I were to apply
my style. Do you have a standard setup, e.g. for emacs?
It's using standard 8 char wide
Corinna Vinschen wrote:
It's using standard 8 char wide tabs. I'm using vi with `set ts=8
set sw=2', that's all. The tab setting should work with all
editors in default setting. The formatting used is consistent with
http://www.gnu.org/prep/standards_toc.html.
OK, it's not what I use but
On Fri, Feb 01, 2002 at 10:08:49AM -0500, Pierre A. Humblet wrote:
Ah, but I am pretty sure you have one already (a few years back).
Really? That's a good thing. I don't have a list of all the
people who already sent an assignment, unfortunately.
Is it a problem for you to assign
On Fri, Feb 01, 2002 at 10:08:49AM -0500, Pierre A. Humblet wrote:
I hoped to get an assignment from you so that we never have to ask
for that later.
Ah, but I am pretty sure you have one already (a few years back).
I don't see any record of this. Do you have specifics? Like who you
sent
At 11:26 AM 1/30/02 +0100, Corinna Vinschen wrote:
On Tue, Jan 29, 2002 at 09:32:06PM -0500, Pierre A. Humblet wrote:
I think you're right that we should always look for the SID in
/etc/passwd at that point. The problem is exactly the startup of
cygrunsrv with no CYGWIN setting in the system
On Tue, Jan 29, 2002 at 09:32:06PM -0500, Pierre A. Humblet wrote:
When ntsec is not defined, internal_getlogin matches the
Windows username with the pw_name's in passwd to find the uid.
When ntsec is defined, internal_getlogin scans passwd by sid's.
Cygwin user names can then be different
At 07:41 PM 1/23/02 +0100, Corinna Vinschen wrote:
On Wed, Jan 23, 2002 at 01:22:29PM -0500, Pierre A. Humblet wrote:
OK, but can you give suggestions about how to debug processes
started under cygrunsrv? I tried to have cygrunsrv start a shell
and put strace in the shell script. However the
On Tue, Jan 29, 2002 at 09:32:06PM -0500, Pierre A. Humblet wrote:
--- how-to-debug-cygwin.txt.in Tue Jan 29 20:08:10 2002
+++ how-to-debug-cygwin.txtTue Jan 29 20:17:50 2002
@@ -11,7 +11,9 @@
1. The first thing you'll need to do is to build cygwin1.dll and your crashed
application from
Corinna Vinschen wrote:
Hi Corinna, I have rearranged the order of your questions.
The registry you're trying to access, is that a key below HKCU or
HKLM?
Special keys:
HKLM
SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Perflib\\009
and
HKEY_PERFORMANCE_DATA
Although the first key above
On Fri, Jan 25, 2002 at 09:57:02AM -0500, Pierre A. Humblet wrote:
The impersonated one, after setuid()
No problem whatsoever with the creator (self in Microsoft language).
In which situation does the application try to read the
registry key, before or after the successful setuid() call?
On Thu, Jan 24, 2002 at 02:56:49PM -0500, Pierre A. Humblet wrote:
Corinna Vinschen wrote:
However, I've just checked in a change which should create a useful
DACL for the primary token created by DuplicateTokenEx() in the
create_token() function. It uses the function `sec_user()' which
Corinna Vinschen wrote:
Sorry but I don't see what you've tested. The patch should address
your problem with the access rights of the impersonation token.
The attachment has a printout of the security info of the impersonation
token. Its DACL is not set the way you intend to have it, in fact
On Mon, Jan 21, 2002 at 10:40:18AM -0500, Pierre A. Humblet wrote:
Corinna Vinschen wrote:
On Fri, Jan 18, 2002 at 07:46:03PM -0500, Pierre A. Humblet wrote:
Entry in passwd (note Cygwin name != Windows name)
On Fri, Jan 18, 2002 at 07:46:03PM -0500, Pierre A. Humblet wrote:
The real problem is that following setuid(), the ACL (not default
ACL) of the impersonation token (which is inherited from the
default ACL of the process token) makes the impersonation
token non-accessible by its user
At 05:06 PM 1/19/02 +0100, Corinna Vinschen wrote:
On Fri, Jan 18, 2002 at 07:46:03PM -0500, Pierre A. Humblet wrote:
3) Why is it necessary to set the PrimaryGroup in the
process token in setegid()?
No, the primary group is used also to create object DACLs.
When setting the PrimaryGroup,
On Sat, Jan 19, 2002 at 04:52:18PM -0500, Pierre A. Humblet wrote:
At 05:06 PM 1/19/02 +0100, Corinna Vinschen wrote:
On Fri, Jan 18, 2002 at 07:46:03PM -0500, Pierre A. Humblet wrote:
3) Why is it necessary to set the PrimaryGroup in the
process token in setegid()?
No, the primary
At 12:33 AM 1/20/02 +0100, you wrote:
On Sat, Jan 19, 2002 at 04:52:18PM -0500, Pierre A. Humblet wrote:
The problem is that in contrast to POSIX the PrimaryGroup is
restricted to the Groups already listed in the access token
of the process. So it will fail if the primary group is set
only for
At 06:38 PM 12/30/01 +0100, Corinna Vinschen wrote:
On Sun, Dec 30, 2001 at 11:26:15AM -0500, Pierre A. Humblet wrote:
At 11:15 PM 12/29/01 +0100, Corinna Vinschen wrote:
While I am at it, here is another weird observation:
base case above: prog reads some registry key. Succeeds.
cases 1 and
On Sun, Dec 30, 2001 at 11:26:15AM -0500, Pierre A. Humblet wrote:
At 11:15 PM 12/29/01 +0100, Corinna Vinschen wrote:
You are reading my mind! I tried it without being administrator.
Now open_local_policy () goes OK but in get_priv_list ()
calls to LsaEnumerateAccountRights() (that succeed
On Sat, Dec 29, 2001 at 03:23:01PM -0500, Pierre A. Humblet wrote:
Bug in security.cc:
The intent of open_local_policy() is to return an INVALID
handle if the call to LsaOpenPolicy() fails. Unfortunately
the failed call changes the value of lsa. The fix is obvious.
Thanks for the heads up.
20 matches
Mail list logo
