file() and Win32 security attributes

You could avoid rewriting a lot of code by adding a call to
win32security.SetFileSecurity after the file is closed.
Alternately, you can change the default permissions for
new files using win32security.SetTokenInformation to modify
TokenDefaultDacl, but that gets more complicated. Also, it
doesn't apply if the directory it's created in has an inheritable
DACL.
hth
Roger

"Gerson Kurz" <ge*********@t-online.de> wrote in message
news:40**************@news.t-online.de...

Hi all, a quick question: how can I force file() to create files that
have "ALL ACCESS FOR EVERYONE" security attributes? Other than by a
major rewrite of my existing code modules replacing the existing
"native-python" code by win32file / win32security calls?

In case you're wondering what is happening here:

- user A with admin rights logs on to NT and uses python to create a
file
- user A logs off
- user B without admin rights logs on to NT and uses python to access
said file -> doesn't work, because B has no admin rights and cannot
access files created by an administrator.

Most feasible solution is AAFE, because a more finegrained ACL is a
nightmare to maintain :)

I'm running into a situation where the first call to PyCG_Collect during a
Py_Finalize, is dying a horrible death and throwing an exception. It is
after *MANY* iterations of the GC loop, so I haven't pinpointed where
exactly it is happening.

Some notes - this is with Python 2.3 BTW, on Windows.

1. this happens in some code where I'm initializing Python, doing some
script/module stuff, finalizing Python, and then doing the process again
2. it happens on the SECOND time, during the Py_Finalize
3. it only seems to happen if I've used the zip importer
4. it DOES NOT happen in a trivial test program I wrote that doesn't have
all the massive script baggage in my real program

My real program has all sorts of custom C types, dictionary mangles, etc.
I'm looking for clues as to what kinds of programming problems with my
custom types could cause PyGC_Collect to go nuts. I've tried to be very
careful about my reference counts.

"Paul Miller" <pa**@fxtech.com> wrote in message
news:6.*******************************@mail.fxtech .com...

I'm running into a situation where the first call to PyCG_Collect during a Py_Finalize, is dying a horrible death and throwing an exception. It is
after *MANY* iterations of the GC loop, so I haven't pinpointed where
exactly it is happening.

Some notes - this is with Python 2.3 BTW, on Windows.

The most recent one? I belive 2.3.3 had some bug fixes in this area.

tjr

Some notes - this is with Python 2.3 BTW, on Windows.

The most recent one? I belive 2.3.3 had some bug fixes in this area.

Really? I'm running 2.3.2. I'll check it out - thanks!

Some notes - this is with Python 2.3 BTW, on Windows.

The most recent one? I belive 2.3.3 had some bug fixes in this area.

Nope - didn't seem to make a difference.

In article <ma*************************************@python.or g>,
Paul Miller <pa**@fxtech.com> wrote:

I'm running into a situation where the first call to PyCG_Collect during a
Py_Finalize, is dying a horrible death and throwing an exception. It is
after *MANY* iterations of the GC loop, so I haven't pinpointed where
exactly it is happening.

Some notes - this is with Python 2.3 BTW, on Windows.

1. this happens in some code where I'm initializing Python, doing some
script/module stuff, finalizing Python, and then doing the process again
2. it happens on the SECOND time, during the Py_Finalize
3. it only seems to happen if I've used the zip importer
4. it DOES NOT happen in a trivial test program I wrote that doesn't have
all the massive script baggage in my real program

What's the exception and stack trace? Are you using weakrefs at all?
--
Aahz (aa**@pythoncraft.com) <*> http://www.pythoncraft.com/

"Do not taunt happy fun for loops. Do not change lists you are looping over."
--Remco Gerlich, comp.lang.python

Paul Miller <pa**@fxtech.com> writes:

My real program has all sorts of custom C types, dictionary mangles,
etc. I'm looking for clues as to what kinds of programming problems
with my custom types could cause PyGC_Collect to go nuts.

Unfortunately, almost any problem can cause PyGC_Collect to go nuts!
It rarely turns out to be a problem with the cycle collector itself.

A debug build of Python is always a good thing to try in these
circumstances.

Cheers,
mwh

--
This song is for anyone ... fuck it. Shut up and listen.
-- Eminem, "The Way I Am"

Gerson Kurz wrote:

Hi all, a quick question: how can I force file() to create files that
have "ALL ACCESS FOR EVERYONE" security attributes? Other than by a
major rewrite of my existing code modules replacing the existing
"native-python" code by win32file / win32security calls?

In case you're wondering what is happening here:

- user A with admin rights logs on to NT and uses python to create a
file
- user A logs off
- user B without admin rights logs on to NT and uses python to access
said file -> doesn't work, because B has no admin rights and cannot
access files created by an administrator.

Most feasible solution is AAFE, because a more finegrained ACL is a
nightmare to maintain :)

If you have win2k, install xcacls:
http://www.microsoft.com/windows2000...g/xcacls-o.asp

I believe XP and 2003 have it by default.

Play around with the command line version until you have it do what you
want, then perhaps subclass file, and insert permission alteration just
after closing.

- Josiah