[Python-Dev] bzr on dinsdale
If I do "bzr status" in dinsdale:/etc/apache2, I get bzr: ERROR: bzrlib.errors.BzrCheckError: Internal check failed: file u'/etc/init.d/stop-bootlogd' entered as kind 'symlink' id 'stopbootlogd-20070303140018-fe340b888f6e9c69', now of kind 'file' Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/bzrlib/commands.py", line 611, in run_bzr_catch_errors return run_bzr(argv) .. BzrCheckError: Internal check failed: file u'/etc/init.d/stop-bootlogd' entered as kind 'symlink' id 'stopbootlogd-20070303140018-fe340b888f6e9c69', now of kind 'file' bzr 0.11.0 on python 2.4.4.final.0 (linux2) arguments: ['/usr/bin/bzr', 'status'] ** please send this report to [EMAIL PROTECTED] Can somebody experienced with bzr please help? Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal for a new function "open_noinherit" to avoid problems with subprocesses and security risks
""" OT: Argh - my email address is visible in the posting - I am doomed! """ - Original Message - > Martin v. Löwis wrote: > > Do you have a patch implementing that feature? I believe > it's unimplementable in Python 2.x: open() is mapped > to fopen(), which does not support O_NOINHERIT. Yes, I have a patch implemented in pure Python. I got the code on my workplace PC (now I am writing from home, that's why I said I'll post the code later). The patch uses os.fdopen ( os.open (..., ...), ...). It translates IOError into OSError then to raise the same class of exception aso open(). Unfortunately, the patch is ignoring the bufsize argument, so it is only a protoype at this time. I know that open() is mapped to fopen() and fopen does not support close_fds. Thus a correct patch has to be implemented at the C level. It should use open and fdopen instead of fopen - just like the Python prototype. AFAIK in the C stdlib implementation, fopen is implemented based on open anyway. BTW to find out what happens, I had to look to the source distribution for the first time after 3 years of using Python. > If you don't want the subprocess to inherit handles, > why don't you just specify close_fds=True when creating > the subprocess? The subprocess module is a great piece of code, but it has its weeknesses. "close_fds" is one of them. subprocess.py fails on MS Windows if I specify close_fds. And it *cannot* be fixed for MS Windows in the subprocess module. This is due to the different way MS Windows handles handles :-) in child process creation: In Posix, you can just work through the file numbers range and close the ones you don't want/need in the subprocess. This is how close_fds works internally. It closes the fds starting from 3 to MAX_FDs-1, thus only stdin, stdout and stderr are inherited. On MS Windows, AFAIK (correct me if I am wrong), you can only choose either to inherit handles or not *as a whole* - including stdin, stdout and stderr -, when calling CreateProcess. Each handle has a security attribute that specifies whether the handle should be inherited or not - but this has to be specified when creating the handle (in the Windows CreateFile API internally). Thus, on MS Windows, you can either choose to inherit all files opened with "open" + [stdin, stdout, stderr], or to not inherit any files (meaning even stdin, stdout and stderr will not be inherited). In a platform-independent program, close_fds is therefore not an option. Henning ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal for a new function "open_noinherit" to avoid problems with subprocesses and security risks
> Yes, I have a patch implemented in pure Python. > > I got the code on my workplace PC (now I am writing from home, > that's why I said I'll post the code later). > > The patch uses os.fdopen ( os.open (..., ...), ...). > It translates IOError into OSError then to raise the same class > of exception aso open(). Hmm. I don't think I could accept such an implementation (whether in Python or in C). That's very hackish. > AFAIK in the C stdlib implementation, fopen is implemented > based on open anyway. Sure - and in turn, open is implemented on CreateFile. However, I don't think I would like to see an fopen implementation in Python. Python 3 will drop stdio entirely; for 2.x, I'd be cautious to change things because that may break other things in an unexpected manner. > On MS Windows, AFAIK (correct me if I am wrong), you can > only choose either to inherit handles or not *as a whole* > - including stdin, stdout and stderr -, when calling CreateProcess. I'm not sure. In general, that seems to be true. However, according to the ReactOS sources at http://www.reactos.org/generated/doxygen/dd/dda/dll_2win32_2kernel32_2process_2create_8c-source.html#l00624 Windows will duplicate stdin,stdout,stderr from the parent process even if bInheritHandles is false, provided that no handles are specified in the startupinfo, and provided that the program to be started is a console (CUI) program. > Each handle has a security attribute that specifies whether the > handle should be inherited or not - but this has to be specified > when creating the handle (in the Windows CreateFile API internally). Not necessarily. You can turn on the flag later, through SetHandleInformation. > Thus, on MS Windows, you can either choose to inherit all > files opened with "open" + [stdin, stdout, stderr], > or to not inherit any files (meaning even stdin, stdout and stderr > will not be inherited). > > In a platform-independent program, close_fds is therefore not an option. ... assuming you care about whether stdin,stdout,stderr are inherited to GUI programs. If the child process makes no use of stdin/stdout, you can safely set close_fds to true. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] bzr on dinsdale
Martin v. Löwis wrote: > If I do "bzr status" in dinsdale:/etc/apache2, I get > > BzrCheckError: Internal check failed: file u'/etc/init.d/stop-bootlogd' > entered as kind 'symlink' id > 'stopbootlogd-20070303140018-fe340b888f6e9c69', now of kind 'file' > > bzr 0.11.0 on python 2.4.4.final.0 (linux2) > arguments: ['/usr/bin/bzr', 'status'] > > ** please send this report to [EMAIL PROTECTED] > > Can somebody experienced with bzr please help? Bzr allow kind changes only starting from version 0.15, for old versions you should first remove file from version control with 'bzr rm' and then add again with 'bzr add'. -- Dmitry Vasiliev http://hlabs.spb.ru ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] bzr on dinsdale
> Bzr allow kind changes only starting from version 0.15, for old versions > you should first remove file from version control with 'bzr rm' and then > add again with 'bzr add'. Thanks! that worked fine. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal for a new function "open_noinherit" to avoid problems with subprocesses and security risks
> "Martin v. Löwis" wrote:
>> Yes, I have a patch implemented in pure Python.
>>
>> I got the code on my workplace PC (now I am writing from home,
>> that's why I said I'll post the code later).
>>
>> The patch uses os.fdopen ( os.open (..., ...), ...).
>> It translates IOError into OSError then to raise the same class
>> of exception aso open().
>
> Hmm. I don't think I could accept such an implementation
> (whether in Python or in C). That's very hackish.
Well, if this is your opinion...
Take a look at the fopen implementation in stdio's fopen.c:
# I found it via Google Code Search in the directory
src/libc/ansi/stdio/fopen.c
# of http://clio.rice.edu/djgpp/win2k/djsr204_alpha.zip
FILE *
fopen(const char *file, const char *mode)
{
FILE *f;
int fd, rw, oflags = 0;
...
fd = open(file, oflags, 0666);
if (fd < 0)
return NULL;
f->_cnt = 0;
f->_file = fd;
f->_bufsiz = 0;
...
}
...
return f;
}
As you can see, at the C level, basically "fopen" is "open" with a little
code
around it to parse flags etc. It's the same kind of hackish code.
And (apart from the ignored bufsize argument) the prototype is working fine.
I have to admit, though, that I am only using it on regular files.
Anyway, I don't want to argue about the implementation of a patch.
The fact is that until now the python programmer does not have an
easy, platform-independent option to open files non-inheritable.
As you mentioned yourself, the only way to work around it
in a platform-independent manner, IS VERY HACKISH.
So, shouldn't this hackish-ness better be hidden in the library
instead of leaving it as an execise to the common programmer?
The kind of errors I mentioned ("permission denied" errors that
seem to occur without an obvious reason) have cost me at least
two weeks of debugging the hard way (with ProcessExplorer etc)
and caused my manager to loose his trust in Python at all...
I think it is well worth the effort to keep this trouble away from
the Python programmers if possible.
And throughout the standard library modules, "open" is used,
causing these problems as soon as sub-processes come into play.
Apart from shutil.copyfile, other examples of using open that can cause
trouble are in socket.py (tell me any good reason why socket handles
should be inherited to child processes) and even in logging.py.
For example, I used RotatingFileHandler for logging my daemon
program activity. Sometimes, the logging itself caused errors,
when a still-running child process had inherited the log file handle
and log rotation occured.
>
>> AFAIK in the C stdlib implementation, fopen is implemented
>> based on open anyway.
>
> Sure - and in turn, open is implemented on CreateFile.
> However, I don't think I would like to see an fopen
> implementation in Python. Python 3 will drop stdio entirely;
> for 2.x, I'd be cautious to change things because that
> may break other things in an unexpected manner.
Yeah, if you think it should not be included in 2.x,
then the handle inheritance problem should at least be considered
in the PEPs [(3116, "New I/O"), (337, "Logging Usage in the Standard
Modules")]
>
>> On MS Windows, AFAIK (correct me if I am wrong), you can
>> only choose either to inherit handles or not *as a whole*
>> - including stdin, stdout and stderr -, when calling CreateProcess.
>
> I'm not sure. In general, that seems to be true. However,
> according to the ReactOS sources at
>
> http://www.reactos.org/generated/doxygen/dd/dda/dll_2win32_2kernel32_2process_2create_8c-source.html#l00624
>
> Windows will duplicate stdin,stdout,stderr from the parent
> process even if bInheritHandles is false, provided that
> no handles are specified in the startupinfo, and provided
> that the program to be started is a console (CUI) program.
>
>> Each handle has a security attribute that specifies whether the
>> handle should be inherited or not - but this has to be specified
>> when creating the handle (in the Windows CreateFile API internally).
>
> Not necessarily. You can turn on the flag later, through
> SetHandleInformation.
So do you think that a working "close_fds" could be implemented
for Windows as well?
Explicitly turning off the inheritance flag for all child handles except
stdin, stdout and stderr in subprocess / popen (the equivalent to
what close_fds does for Posix) - that's what I call hackish.
And I doubt that it is possible at all, for two reasons:
- you have to KNOW all the handles.
- due to the different process creation in Windows (there's no fork),
you had to set the inheritance flags afterwards
- all this is not thread-safe.
>
>> Thus, on MS Windows, you can either choose to inherit all
>> files opened with "open" + [stdin, stdout, stderr],
>> or to not inherit any files (meaning even stdin, stdout and stderr
>> will not be inherited).
>>
>> In a platform-independent program, close_fds is therefore not an option.
>
> ... assuming you care about whether stdin,stdout,stderr are inherited
> to GUI pro
Re: [Python-Dev] Proposal for a new function "open_noinherit" to avoid problems with subprocesses and security risks
The kind of errors I mentioned ("permission denied" errors that
seem to occur without an obvious reason) have cost me at least
two weeks of debugging the hard way (with ProcessExplorer etc)
and caused my manager to loose his trust in Python at all...
I think it is well worth the effort to keep this trouble away from
the Python programmers if possible.
And throughout the standard library modules, "open" is used,
causing these problems as soon as sub-processes come into play.
Apart from shutil.copyfile, other examples of using open that can cause
trouble are in socket.py (tell me any good reason why socket handles
should be inherited to child processes) and even in logging.py.
For example, I used RotatingFileHandler for logging my daemon
program activity. Sometimes, the logging itself caused errors,
when a still-running child process had inherited the log file handle
and log rotation occured.
I just wanted to express to the group at large that these experiences aren't
just Henning's; we spent a *tremendous* amount of time and effort debugging
serious problems that arose from file handles getting shared to subprocesses
where it wasn't really expected. Specifically, the RotatingFileHandler
example above. It blatantly just breaks when subprocesses are used and its
an extremely obtuse process to discover why.
It was very costly to the company because it came up at a bad time and was
*so* obtuse of an error. At first it looked like some sort of thread-safety
problem, so a lot of prying went into that before we got stumped... after
all, we *knew* no other process touched that file, and the logging module
(and RotatingFileHandler) claimed and looked thread-safe, so.. how could it
be having a Permission Denied error when it very clearly is closing the file
before rotating it? Eventually the culprit was found, but it was very
painful.
A couple similar issues have arisen since, and they're only slightly easier
to debug once you are expecting it. But the fact that the simple and obvious
features provided in the stdlib break as a result of you launching a
subprocess at some point sorta sucks :)
So, yeah. Anything even remotely or vaguely approaching Henning's patch
would be really, really appreciated.
--SH
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal for a new function "open_noinherit" to avoid problems with subprocesses and security risks
> As you can see, at the C level, basically "fopen" is "open" with a
> little code around it to parse flags etc. It's the same kind of hackish code.
"little code" is quite an understatement. In Microsoft's C library
(which we would have to emulate), the argument parsing of fopen is
120 lines of code. In addition, that code changes across compiler
versions (where VS 2005 adds additional error checking).
> Anyway, I don't want to argue about the implementation of a patch.
> The fact is that until now the python programmer does not have an
> easy, platform-independent option to open files non-inheritable.
> As you mentioned yourself, the only way to work around it
> in a platform-independent manner, IS VERY HACKISH.
> So, shouldn't this hackish-ness better be hidden in the library
> instead of leaving it as an execise to the common programmer?
Putting it into the library is fine. However, we need to find
an implementation strategy that meets the user's needs, and
is still maintainable.
Python 3 will offer a clean solution, deviating entirely from
stdio. For 2.x, we need to find a better solution than the
one you proposed.
> I think it is well worth the effort to keep this trouble away from
> the Python programmers if possible.
I don't argue about efforts - I argue about your proposed solution.
> Apart from shutil.copyfile, other examples of using open that can cause
> trouble are in socket.py (tell me any good reason why socket handles
> should be inherited to child processes) and even in logging.py.
On Unix, it is *very* common to inherit socket handles to child
processes. The parent process opens the socket, and the child
processes perform accept(3). This allows many processes to
serve requests on the same port. In Python,
SocketServer.Forking*Server rely on this precise capability.
>> Sure - and in turn, open is implemented on CreateFile.
>> However, I don't think I would like to see an fopen
>> implementation in Python. Python 3 will drop stdio entirely;
>> for 2.x, I'd be cautious to change things because that
>> may break other things in an unexpected manner.
>
> Yeah, if you think it should not be included in 2.x,
> then the handle inheritance problem should at least be considered
> in the PEPs [(3116, "New I/O"), (337, "Logging Usage in the Standard
> Modules")]
I didn't say that a solution shouldn't be included in 2.x.
I said *your* solution shouldn't be. In 3.x, your solution
won't apply, sine Python won't be using stdio (so
fdopen becomes irrelevant)
>>> Each handle has a security attribute that specifies whether the
>>> handle should be inherited or not - but this has to be specified
>>> when creating the handle (in the Windows CreateFile API internally).
>>
>> Not necessarily. You can turn on the flag later, through
>> SetHandleInformation.
>
> So do you think that a working "close_fds" could be implemented
> for Windows as well?
No. close_fds should have the semantics of only closing the handles
for that subprocess. SetHandleInformation applies to the parent
process, and *all* subprocesses. So this is different from close_fds.
> Explicitly turning off the inheritance flag for all child handles except
> stdin, stdout and stderr in subprocess / popen (the equivalent to
> what close_fds does for Posix) - that's what I call hackish.
I didn't propose that, and it wouldn't be the equivalent. In POSIX,
the closing occurs in the child process. This is not possible on
Windows, as there is no fork().
> And I doubt that it is possible at all, for two reasons:
> - you have to KNOW all the handles.
> - due to the different process creation in Windows (there's no fork),
> you had to set the inheritance flags afterwards
> - all this is not thread-safe.
All true, and I did not suggest to integrate SetHandleInformation
into subprocess. I *ONLY* claimed that you can change the flag
after the file was opened.
With that API, it would be possible to provide cross-platform
access to the close-on-exec flag. Applications interested in setting
it could then set it right after opening the file.
> Apart from the fact that this is not possible on MS Windows, it won't
> solve the problem!
> (Because then I couldn't use all those standard modules that use open
> *without* FD_CLOEXEC).
>
> The fact is that the combination ("multi-threading", "subprocess
> creation", "standard modules")
> simply *does not work* flawlessly and produces errors that are hard to
> understand.
> And probably most progammers are not even aware of the problem.
> That's the main reason why I posted here.
I don't see how your proposed change solves that. If there was
an "n" flag, then the modules in the standard library that open
files still won't use it.
Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal for a new function "open_noinherit" to avoid problems with subprocesses and security risks
On Sat, Jun 23, 2007 at 08:39:38AM -0700, Stephen Hansen wrote: > I just wanted to express to the group at large that these experiences aren't > just Henning's; we spent a *tremendous* amount of time and effort debugging > serious problems that arose from file handles getting shared to subprocesses > where it wasn't really expected. I've also encountered this when writing programs that are SCGI servers that do a fork. SCGI is like FastCGI; the HTTP server passes requests to a local server using a custom protocol. If the fork doesn't close the SCGI server port, then Apache does nothing until the forked subprocess exits, because the subprocess is keeping the request socket open and alive. One fix is to always use subprocess.Popen and specify that close_fd=True, which wasn't difficult for me, but I can imagine that an easy way to set close-on-exec would be simpler in other cases. --amk ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal for a new function "open_noinherit" to avoid problems with subprocesses and security risks
Stephen, thank you for speaking it out loud on python-dev. And you know better english words like "tremendous" and "obtuse" (whatever that means:-) that express what a PITA this really is. When I said it took me two weeks, that's actually not the truth. It was even more. The first problem was with RotatingLogHandler, and just like you, I first thought it was a threading problem. Thus I wrote my own version of RotationLogHandler, which builds new log file name with a timestamp instead of renaming the old log files. Actually, the point when I found out that indeed subprocesses were causing problems was when I had the program running on about 50 computers (for different clients) and for some clients the program would run very well, while for other clients there were often errors - suddenly it came to my mind that the clients with the errors were those who used a subprocess for sending e-mail via MAPI, whereas the clients who didn't experience problems were those who used smtplib for sending e-mail (no subprocesses). And then it took me a few days to write my replacement open function and to replace each occurence of "open" with the replacement function. And then, another few days later, a client told me that the errors *still* occured (although in rare cases). At first I built a lot of tracing and debugging into the MAPI subprocess "sendmail.exe". Finally I found out that it was actually shutil.filecopy that caused the error. Of course, I hadn't searched for "open" in the whole bunch of standard modules... Henning ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal for a new function "open_noinherit" to avoid problems with subprocesses and security risks
> One fix is to always use subprocess.Popen and specify that > close_fd=True, which wasn't difficult for me, but I can imagine that > an easy way to set close-on-exec would be simpler in other cases. I think the complaint is not so much about simplicity, but correctness. close_fd also closes stdin/stdout/stderr, which might be undesirable and differs from POSIX. In any case, providing a uniform set-close-on-exec looks fine to me, provided it is implementable on all interesting platforms. I'm -0 on adding "n" to open, and -1 for adding if it means to reimplement fopen. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal for a new function "open_noinherit" to avoid problems with subprocesses and security risks
Hi, I think the complaint is not so much about simplicity, but correctness. close_fd also closes stdin/stdout/stderr, which might be undesirable and differs from POSIX. According to the docs, stdin/stdout and stderr are not closed ( http://docs.python.org/lib/node529.html) Matthieu ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal for a new function "open_noinherit" to avoid problems with subprocesses and security risks
> I think the complaint is not so much about simplicity, but correctness. > close_fd also closes stdin/stdout/stderr, which might be undesirable > and differs from POSIX. > > > According to the docs, stdin/stdout and stderr are not closed ( > http://docs.python.org/lib/node529.html) I don't get your point: The docs says explicitly "Unix only". Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Summary of Tracker Issues
ACTIVITY SUMMARY (06/17/07 - 06/24/07) Tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 1645 open ( +0) / 8584 closed ( +0) / 10229 total ( +0) Average duration of open issues: 836 days. Median duration of open issues: 784 days. Open Issues Breakdown open 1645 ( +0) pending 0 ( +0) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Issues with PEP 3101 (string formatting)
I haven't responded to this thread because I was hoping some of the original proponents of the feature would come out to defend it. (Remember, 3101 is a synthesis of a lot of people's ideas gleaned from many forum postings - In some cases I am willing to defend particular aspects of the PEP, and in others I just write down what I think the general consensus is.) That being said - from what I've read so far, the evidence on both sides of the argument seems anecdotal to me. I'd rather wait and see what more people have to say on the topic. -- Talin Aurélien Campéas wrote: > On Tue, Jun 19, 2007 at 08:20:25AM -0700, Guido van Rossum wrote: >> Those are valid concerns. I'm cross-posting this to the python-3000 >> list in the hope that the PEP's author and defendents can respond. I'm >> sure we can work something out. > > Thanks to raise this. It is horrible enough that I feel obliged to > de-lurk. > > -10 on this part of PEP3101. > > >> Please keep further discussion on the [EMAIL PROTECTED] list. >> >> --Guido >> >> On 6/19/07, Chris McDonough <[EMAIL PROTECTED]> wrote: >>> Wrt http://www.python.org/dev/peps/pep-3101/ >>> >>> PEP 3101 says Py3K should allow item and attribute access syntax >>> within string templating expressions but "to limit potential security >>> issues", access to underscore prefixed names within attribute/item >>> access expressions will be disallowed. > > People talking about potential security issues should have an > obligation to show how their proposals *really* improve security (in > general); this is of course, a hard thing to do; mere hand-waving is > not sufficient. > >>> I am a person who has lived with the aftermath of a framework >>> designed to prevent data access by restricting access to underscore- >>> prefixed names (Zope 2, ahem), and I've found it's very hard to >>> explain and justify. As a result, I feel that this is a poor default >>> policy choice for a framework. > > And it's even poorer in the context of a language (for it's probably > harder to escape language-level restrictions than framework > obscurities ...). > >>> In some cases, underscore names must become part of an object's >>> external interface. Consider a URL with one or more underscore- >>> prefixed path segment elements (because prefixing a filename with an >>> underscore is a perfectly reasonable thing to do on a filesystem, and >>> path elements are often named after file names) fed to a traversal >>> algorithm that attempts to resolve each path element into an object >>> by calling __getitem__ against the parent found by the last path >>> element's traversal result. Perhaps this is poor design and >>> __getitem__ should not be consulted here, but I doubt that highly >>> because there's nothing particularly special about calling a method >>> named __getitem__ as opposed to some method named "traverse". > > This is trying to make a technical argument, but the 'consenting > adults' policy might be enough. In my experience, zope forbiding > access to _ prefixed attributes just led to work around the > limitation, thus adding more useless indirection to an already crufty > code base. The result is more obfuscation and probably even less > security (as in auditability of the code). > >>> The only precedent within Python 2 for this sort of behavior is >>> limiting access to variables that begin with __ and which do not end >>> with __ to the scope defined by a class and its instances. I >>> personally don't believe this is a very useful feature, but it's >>> still only an advisory policy and you can worm around it with enough >>> gyrations. > > FWIW I've come to never use __attrs. The obfuscation feature seems to > bring nothing but pain (the few times I've fell into that trap as a > beginner python programmer). > >>> Given that security is a concern at all, the only truly reasonable >>> way to "limit security issues" is to disallow item and attribute >>> access completely within the string templating expression syntax. It >>> seems gratuituous to me to encourage string templating expressions >>> with item/attribute access, given that you could do it within the >>> format arguments just as easily in the 99% case, and we've (well... >>> I've) happily been living with that restriction for years now. >>> >>> But if this syntax is preserved, there really should be no *default* >>> restrictions on the traversable names within an expression because >>> this will almost certainly become a hard-to-explain, hard-to-justify >>> bug magnet as it has become in Zope. > > I'd add that Zope in general looks to me like a giant collection of > python anti-patterns and as such can be used as a clue source about > what not to do, especially what not to include in Py3k. > > I don't want to offense people, well no more than necessary (imho zope > *is* an offense to common sense in many ways), but that's the opinion > from someone who earns its living mostly from zope/plone products > dev. and main
