/usr/share/pyshared/zope.security-3.8.3.egg-info/PKG-INFO is in python-zope.security 3.8.3-2ubuntu1.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 843 844 845 846 847 848 849 850 851 852 853 854 855 856 857 858 859 860 861 862 863 864 865 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 902 903 | Metadata-Version: 1.0
Name: zope.security
Version: 3.8.3
Summary: Zope Security Framework
Home-page: http://pypi.python.org/pypi/zope.security
Author: Zope Foundation and Contributors
Author-email: zope-dev@zope.org
License: ZPL 2.1
Description: The Security framework provides a generic mechanism to implement security
policies on Python objects.
.. contents::
==============
Zope3 Security
==============
Introduction
------------
The Security framework provides a generic mechanism to implement security
policies on Python objects. This introduction provides a tutorial of the
framework explaining concepts, design, and going through sample usage from the
perspective of a Python programmer using the framework outside of Zope.
Definitions
-----------
Principal
~~~~~~~~~
A generalization of a concept of a user.
Permission
~~~~~~~~~~
A kind of access, i.e. permission to READ vs. permission to WRITE.
Fundamentally the whole security framework is organized around checking
permissions on objects.
Purpose
-------
The security framework's primary purpose is to guard and check access to
Python objects. It does this by providing mechanisms for explicit and
implicit security checks on attribute access for objects. Attribute names are
mapped onto permission names when checking access and the implementation of
the security check is defined by the security policy, which receives the
object, the permission name, and an interaction.
Interactions are objects that represent the use of the system by one or more
principals. An interaction contains a list of participations, which
represents the way a single principal participates in the interaction. An
HTTP request is one example of a participation.
Its important to keep in mind that the policy provided is just a default, and
it can be substituted with one which doesn't care about principals or
interactions at all.
Framework Components
--------------------
Low Level Components
~~~~~~~~~~~~~~~~~~~~
These components provide the infrastructure for guarding attribute access and
providing hooks into the higher level security framework.
Checkers
~~~~~~~~
A checker is associated with an object kind, and provides the hooks that map
attribute checks onto permissions deferring to the security manager (which in
turn defers to the policy) to perform the check.
Additionally, checkers provide for creating proxies of objects associated with
the checker.
There are several implementation variants of checkers, such as checkers that
grant access based on attribute names.
Proxies
~~~~~~~
Wrappers around Python objects that implicitly guard access to their wrapped
contents by delegating to their associated checker. Proxies are also viral in
nature, in that values returned by proxies are also proxied.
High Level Components
---------------------
Security Management
~~~~~~~~~~~~~~~~~~~
Provides accessors for setting up interactions and the global security policy.
Interaction
~~~~~~~~~~~
Stores transient information on the list of participations.
Participation
~~~~~~~~~~~~~
Stores information about a principal participating in the interaction.
Security Policy
~~~~~~~~~~~~~~~
Provides a single method that accepts the object, the permission, and the
interaction of the access being checked and is used to implement the
application logic for the security framework.
Narrative (agent sandbox)
-------------------------
As an example we take a look at constructing a multi-agent distributed system,
and then adding a security layer using the Zope security model onto it.
Scenario
~~~~~~~~
Our agent simulation consists of autonomous agents that live in various agent
homes/sandboxes and perform actions that access services available at their
current home. Agents carry around authentication tokens which signify their
level of access within any given home. Additionally agents attempt to migrate
from home to home randomly.
The agent simulation was constructed separately from any security aspects.
Now we want to define and integrate a security model into the simulation. The
full code for the simulation and the security model is available separately;
we present only relevant code snippets here for illustration as we go through
the implementation process.
For the agent simulation we want to add a security model such that we group
agents into two authentication groups, "norse legends", including the
principals thor, odin, and loki, and "greek men", including prometheus,
archimedes, and thucydides.
We associate permissions with access to services and homes. We differentiate
the homes such that certain authentication groups only have access to services
or the home itself based on the local settings of the home in which they
reside.
We define the homes/sandboxes
- origin - all agents start here, and have access to all
services here.
- valhalla - only agents in the authentication group 'norse
legend' can reside here.
- jail - all agents can come here, but only 'norse legend's
can leave or access services.
Process
~~~~~~~
Loosely we define a process for implementing this security model
- mapping permissions onto actions
- mapping authentication tokens onto permissions
- implementing checkers and security policies that use our
authentication tokens and permissions.
- binding checkers to our simulation classes
- inserting the hooks into the original simulation code to add
proxy wrappers to automatically check security.
- inserting hooks into the original simulation to register the
agents as the active principal in an interaction.
Defining a Permission Model
~~~~~~~~~~~~~~~~~~~~~~~~~~~
We define the following permissions::
NotAllowed = 'Not Allowed'
Public = Checker.CheckerPublic
TransportAgent = 'Transport Agent'
AccessServices = 'Access Services'
AccessAgents = 'Access Agents'
AccessTimeService = 'Access Time Services'
AccessAgentService = 'Access Agent Service'
AccessHomeService = 'Access Home Service'
and create a dictionary database mapping homes to authentication groups which
are linked to associated permissions.
Defining and Binding Checkers
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Checkers are the foundational unit for the security framework. They define
what attributes can be accessed or set on a given instance. They can be used
implicitly via Proxy objects, to guard all attribute access automatically or
explicitly to check a given access for an operation.
Checker construction expects two functions or dictionaries, one is used to map
attribute names to permissions for attribute access and another to do the same
for setting attributes.
We use the following checker factory function::
def PermissionMapChecker(permissions_map={},
setattr_permission_func=NoSetAttr):
res = {}
for k,v in permissions_map.items():
for iv in v:
res[iv]=k
return checker.Checker(res.get, setattr_permission_func)
time_service_checker = PermissionMapChecker(
# permission : [methods]
{'AccessTimeService':['getTime']}
)
with the NoSetAttr function defined as a lambda which always return the
permission `NotAllowed`.
To bind the checkers to the simulation classes we register our checkers with
the security model's global checker registry::
import sandbox_simulation
from zope.security.checker import defineChecker
defineChecker(sandbox_simulation.TimeService, time_service_checker)
Defining a Security Policy
~~~~~~~~~~~~~~~~~~~~~~~~~~
We implement our security policy such that it checks the current agent's
authentication token against the given permission in the home of the object
being accessed::
class SimulationSecurityPolicy:
implements(ISecurityPolicy)
createInteraction = staticmethod(simpleinteraction.createInteraction)
def checkPermission(self, permission, object, interaction):
home = object.getHome()
db = getattr(SimulationSecurityDatabase, home.getId(), None)
if db is None:
return False
allowed = db.get('any', ())
if permission in allowed or ALL in allowed:
return True
if interaction is None:
return False
if not interaction.participations:
return False
for participation in interaction.participations:
token = participation.principal.getAuthenticationToken()
allowed = db.get(token, ())
if permission not in allowed:
return False
return True
There are no specific requirements for the interaction class, so we can just
use `zope.security.simpleinteraction.Interaction`.
Since an interaction can have more than one principal, we check that *all* of
them are given the necessary permission. This is not really necessary since
we only create interactions with a single active principal.
There is some additional code present to allow for shortcuts in defining the
permission database when defining permissions for all auth groups and all
permissions.
Integration
~~~~~~~~~~~
At this point we have implemented our security model, and we need to integrate
it with our simulation model. We do so in three separate steps.
First we make it such that agents only access homes that are wrapped in a
security proxy. By doing this all access to homes and services (proxies have
proxied return values for their methods) is implicitly guarded by our security
policy.
The second step is that we want to associate the active agent with the
security context so the security policy will know which agent's authentication
token to validate against.
The third step is to set our security policy as the default policy for the
Zope security framework. It is possible to create custom security policies at
a finer grained than global, but such is left as an exercise for the reader.
Interaction Access
~~~~~~~~~~~~~~~~~~
The *default* implementation of the interaction management interfaces defines
interactions on a per thread basis with a function for an accessor. This
model is not appropriate for all systems, as it restricts one to a single
active interaction per thread at any given moment. Reimplementing the
interaction access methods though is easily doable and is noted here for
completeness.
Perspectives
~~~~~~~~~~~~
It's important to keep in mind that there is a lot more that is possible using
the security framework than what's been presented here. All of the
interactions are interface based, such that if you need to re-implement the
semantics to suite your application a new implementation of the interface will
be sufficient. Additional possibilities range from restricted interpreters
and dynamic loading of untrusted code to non Zope web application security
systems. Insert imagination here ;-).
Zope Perspective
~~~~~~~~~~~~~~~~
A Zope3 programmer will never commonly need to interact with the low level
security framework. Zope3 defines a second security package over top the low
level framework and authentication sources and checkers are handled via zcml
registration. Still those developing Zope3 will hopefully find this useful as
an introduction into the underpinnings of the security framework.
Code
~~~~
The complete code for this example is available.
- sandbox.py - the agent framework
- sandbox_security.py - the security implementation and binding to the agent
framework.
Authors
~~~~~~~
- Kapil Thangavelu <hazmat at objectrealms.net>
- Guido Wesdorp <guido at infrae.com>
- Marius Gedminas <marius at pov.lt>
======================
Untrusted interpreters
======================
Untrusted programs are executed by untrusted interpreters. Untrusted
interpreters make use of security proxies to prevent un-mediated
access to assets. An untrusted interpreter defines an environment for
running untrusted programs. All objects within the environment are
either:
- "safe" objects created internally by the environment or created in
the course of executing the untrusted program, or
- "basic" objects
- security-proxied non-basic objects
The environment includes proxied functions for accessing objects
outside of the environment. These proxied functions provide the only
way to access information outside the environment. Because these
functions are proxied, as described below, any access to objects
outside the environment is mediated by the target security functions.
Safe objects are objects whose operations, except for attribute
retrieval, and methods access only information stored within the
objects or passed as arguments. Safe objects contained within the
interpreter environment can contain only information that is already
in the environment or computed directly from information that is
included in the environment. For this reason, safe objects created
within the environment cannot be used to directly access information
outside the environment.
Safe objects have some attributes that could (very) indirectly be used
to access assets. For this reason, an untrusted interpreter always
proxies the results of attribute accesses on a safe objects.
Basic objects are safe objects that are used to represent elemental
data values such as strings and numbers. Basic objects require a
lower level of protection than non-basic objects, as will be described
detail in a later section.
Security proxies mediate all object operations. Any operation
access is checked to see whether a subject is authorized to perform
the operation. All operation results other than basic objects are, in
turn, security proxied. Security proxies will be described in greater
detail in a later section. Any operation on a security proxy that
results in a non-basic object is also security proxied.
All external resources needed to perform an operation are security
proxied.
Let's consider the trusted interpreter for evaluating URLs. In
operation 1 of the example, the interpreter uses a proxied method for
getting the system root object. Because the method is proxied, the
result of calling the method and the operation is also proxied.
The interpreter has a function for traversing objects. This function
is proxied. When traversing an object, the function is passed an
object and a name. In operation 2, the function is passed the result
of operation 1, which is the proxied root object and the name 'A'. We
may traverse an object by invoking an operation on it. For example,
we may use an operation to get a sub-object. Because any operation on a
proxied object returns a proxied object or a basic object, the result
is either a proxied object or a basic object. Traversal may also look
up a component. For example, in operation 1, we might look up a
presentation component named "A" for the root object. In this case,
the external object is not proxied, but, when it is returned from the
traversal function, it is proxied (unless it is a a basic object)
because the traversal function is proxied, and the result of calling a
proxied function is proxied (unless the result is a basic object).
Operation 3 proceeds in the same way.
When we get to operation 4, we use a function for computing the
default presentation of the result of operation 3. As with traversal,
the result of getting the default presentation is either a proxied
object or a basic object because the function for getting the default
presentation is proxied.
When we get to the last operation, we have either a proxied object or a
basic object. If the result of operation 4 is a basic object, we
simply convert it to a string and return it as the result page. If
the result of operation 4 is a non-basic object, we invoke a render
operation on it and return the result as a string.
Note that an untrusted interpreter may or may not provide protection
against excessive resource usage. Different interpreters will provide
different levels of service with respect to limitations on resource
usage.
If an untrusted interpreter performs an attribute access, the trusted
interpreter must proxy the result unless the result is a basic object.
In summary, an untrusted interpreter assures that any access to assets
is mediated through security proxies by creating an environment to run
untrusted code and making sure that:
- The only way to access anything from outside of the environment is
to call functions that are proxied in the environment.
- Results of any attribute access in the environment are proxied
unless the results are basic objects.
Security proxies
----------------
Security proxies are objects that wrap and mediate access to objects.
The Python programming language used by Zope defines a set of specific
named low-level operations. In addition to operations, Python objects
can have attributes, used to represent data and methods. Attributes
are accessed using a dot notation. Applications can, and usually do,
define methods to provide extended object behaviors. Methods are
accessed as attributes through the low-level operation named
"__getattribute__". The Python code::
a.b()
invokes 2 operations:
1. Use the low-level `__getattribute__` operation with the name "b".
2. Use the low-level '__call__' operation on the result of the first
operation.
For all operations except the `__getattribute__` and
`__setattribute__` operations, security proxies have a permission
value defined by the permission-declaration subsystem. Two special
permission values indicate that access is either forbidden (never
allowed) or public (always allowed). For all other permission values,
the authorization subsystem is used to decide whether the subject has
the permission for the proxied object. If the subject has the
permission, then access to the operation is allowed. Otherwise, access
is denied.
For getting or setting attributes, a proxy has permissions for getting
and a permission for setting attribute values for a given attribute
name. As described above, these permissions may be one of the two
special permission values indicating forbidden or public access, or
another permission value that must be checked with the authorization
system.
For all objects, Zope defines the following operations to be always public:
comparison
"__lt__", "__le__", "__eq__", "__gt__", "__ge__", "__ne__"
hash
"__hash__"
boolean value
"__nonzero__"
class introspection
"__class__"
interface introspection
"__providedBy__", "__implements__"
adaptation
"__conform__"
low-level string representation
"__repr__"
The result of an operation on a proxied object is a security proxy
unless the result is a basic value.
Basic objects
-------------
Basic objects are safe immutable objects that contain only immutable
subobjects. Examples of basic objects include:
- Strings,
- Integers (long and normal),
- Floating-point objects,
- Date-time objects,
- Boolean objects (True and False), and
- The special (nil) object, None.
Basic objects are safe, so, as described earlier, operations on basic
objects, other than attribute access, use only information contained
within the objects or information passed to them. For this reason,
basic objects cannot be used to access information outside of the
untrusted interpreter environment.
The decision not to proxy basic objects is largely an optimization.
It allows low-level safe computation to be performed without
unnecessary overhead,
Note that a basic object could contain sensitive information, but such
a basic object would need to be obtained by making a call on a proxied
object. Therefore, the access to the basic object in the first place
is mediated by the security functions.
Rationale for mutable safe objects
----------------------------------
Some safe objects are not basic. For these objects, we proxy the
objects if they originate from outside of the environment. We do this
for two reasons:
1. Non-basic objects from outside the environment need to be proxied
to prevent unauthorized access to information.
2. We need to prevent un-mediated change of information from outside of
the environment.
We don't proxy safe objects created within the environment. This is
safe to do because such safe objects can contain and provide access to
information already in the environment. Sometimes the interpreter or
the interpreted program needs to be able to create simple data
containers to hold information computed in the course of the program
execution. Several safe container types are provided for this
purpose.
=======
CHANGES
=======
3.8.3 (2011-09-24)
------------------
- Fixed a regression introduced in 3.8.1: ``zope.location``\'s LocationProxy
did not get a security checker if ``zope.security.decorator`` was not
imported manually. Now ``zope.security.decorator`` is imported in
``zope.security.proxy`` without re-introducing the circular import fixed in
3.8.1.
3.8.2 (2011-05-24)
------------------
- Fix a test that failed on Python 2.7.
3.8.1 (2011-05-03)
------------------
- Fixed circular import beween ``zope.security.decorator`` and
``zope.security.proxy`` which led to an ``ImportError`` when only
importing ``zope.security.decorator``.
3.8.0 (2010-12-14)
------------------
- Added tests for our own ``configure.zcml``.
- Added ``zcml`` extra dependencies, run related tests only if
``zope.configuration`` is available.
- Run tests related to the ``untrustedpython`` functionality only if
``RestrictedPython`` is available.
3.7.3 (2010-04-30)
------------------
- Prefer the standard libraries doctest module to the one from zope.testing.
- Fixed directlyProvides IVocabularyFactory for PermissionIdsVocabulary in
Python code, even if it's unnecessary because IVocabularyFactory is provided
in zcml.
- Removed the dependency on the zope.exceptions package: zope.security.checker
now imports ``DuplicationError`` from zope.exceptions if available, otherwise
it defines a package-specific ``DuplicationError`` class which inherits from
Exception.
3.7.2 (2009-11-10)
------------------
- Added compatibility with Python 2.6 abstract base classes.
3.7.1 (2009-08-13)
------------------
- Fix for LP bug 181833 (from Gustavo Niemeyer). Before "visiting" a
sub-object, a check should be made to ensure the object is still valid.
Because garbage collection may involve loops, if you garbage collect an
object, it is possible that the actions done on this object may modify the
state of other objects. This may cause another round of garbage collection,
eventually generating a segfault (see LP bug). The Py_VISIT macro does the
necessary checks, so it is used instead of the previous code.
3.7.0 (2009-05-13)
------------------
- Made ``pytz`` a soft dependency: the checker for ``pytz.UTC`` is
created / tested only if the package is already present. Run
``bin/test_pytz`` to run the tests with ``pytz`` on the path.
3.6.3 (2009-03-23)
------------------
- Ensure that simple zope.schema's VocabularyRegistry is used for
PermissionVocabulary tests, because it's replaced implicitly in
environments with zope.app.schema installed that makes that tests
fail.
- Fixed a bug in DecoratedSecurityCheckerDescriptor which made
security-wrapping location proxied exception instances throw
exceptions on Python 2.5.
See https://bugs.launchpad.net/zope3/+bug/251848
3.6.2 (2009-03-14)
------------------
- Add zope.i18nmessageid.Message to non-proxied basic types. It's okay, because
messages are immutable. It was done by zope.app.security before.
- Add "__name__" and "__parent__" attributes to list of available by default.
This was also done by zope.app.security package before.
- Added PermissionsVocabulary and PermissionIdsVocabulary vocabularies
to the ``zope.security.permission`` module. They were moved from
the ``zope.app.security`` package.
- Add zcml permission definitions for most common and useful permissions,
like "zope.View" and "zope.ManageContent", as well as for the special
"zope.Public" permission. They are placed in a separate "permissions.zcml"
file, so it can be easily excluded/redefined. They are selected part of
permissions moved from ``zope.app.security`` and used by many zope.*
packages.
- Add `addCheckerPublic` helper function in ``zope.security.testing`` module
that registers the "zope.Public" permission as an IPermission utility.
- Add security declarations for the ``zope.security.permisson.Permission``
class.
- Improve test coverage.
3.6.1 (2009-03-10)
------------------
- Use ``from`` imports instead of ``zope.deferred`` to avoid circular
import problems, thus drop dependency on ``zope.deferredimport``.
- Raise NoInteraction when zope.security.checkPermission is called
without interaction being active (LP #301565).
- Don't define security checkers for deprecated set types from the
"sets" module on Python 2.6. It's discouraged to use them and
`set` and `frozenset` built-in types should be used instead.
- Change package's mailng list address to zope-dev at zope.org as
zope3-dev at zope.org is now retired.
- Remove old zpkg-related files.
3.6.0 (2009-01-31)
------------------
- Install decorated security checker support on LocationProxy from the
outside.
- Added support to bootstrap on Jython.
- Moved the `protectclass` module from `zope.app.security` to this
package to reduce the number of dependencies on `zope.app.security`.
- Moved the <module> directive implementation from `zope.app.security`
to this package.
- Moved the <class> directive implementation from `zope.app.component`
to this package.
3.5.2 (2008-07-27)
------------------
- Made C code compatible with Python 2.5 on 64bit architectures.
3.5.1 (2008-06-04)
------------------
- Add `frozenset`, `set`, `reversed`, and `sorted` to the list of safe
builtins.
3.5.0 (2008-03-05)
------------------
- Changed title for ``zope.security.management.system_user`` to be more
presentable.
3.4.3 - (2009/11/26)
--------------------
- Backported a fix made by Gary Poster to the 3.4 branch:
Fix for LP bug 181833 (from Gustavo Niemeyer). Before "visiting" a
sub-object, a check should be made to ensure the object is still valid.
Because garbage collection may involve loops, if you garbage collect an
object, it is possible that the actions done on this object may modify the
state of other objects. This may cause another round of garbage collection,
eventually generating a segfault (see LP bug). The Py_VISIT macro does the
necessary checks, so it is used instead of the previous code.
3.4.2 - (2009/03/23)
--------------------
- Added dependency 'zope.thread' to setup.py, without the tests were
failing.
- Backported a fix made by Albertas Agejevas to the 3.4 branch. He
fixed a bug in DecoratedSecurityCheckerDescriptor which made
security-wrapping location proxied exception instances throw
exceptions on Python 2.5. See
https://bugs.launchpad.net/zope3/+bug/251848
3.4.1 - 2008/07/27
------------------
- Made C code compatible with Python 2.5 on 64bit architectures.
3.4.0 (2007-10-02)
------------------
- Updated meta-data.
3.4.0b5 (2007-08-15)
--------------------
- Bug: Fixed a circular import in the C implementation.
3.4.0b4 (2007-08-14)
--------------------
- Bug: ``zope.security.management.system_user`` had an ugly/brittle id.
3.4.0b3 (2007-08-14)
--------------------
- ``zope.security`` now works on Python 2.5
- Bug: ``zope.security.management.system_user`` wasn't a valid principal
(didn't provide IPrincipal).
- Bug: Fixed inclusion of doctest to use the doctest module from
``zope.testing``. Now tests can be run multiple times without
breaking. (#98250)
3.4.0b2 (2007-06-15)
--------------------
- Bug: Removed stack extraction in newInteraction. When using eggs this is an
extremly expensive function. The publisher is now more than 10 times faster
when using eggs and about twice as fast with a zope trunk checkout.
3.4.0b1
-------
- Temporarily fixed the hidden (and accidental) dependency on zope.testing to
become optional.
Note: The releases between 3.2.0 and 3.4.0b1 where not tracked as an
individual package and have been documented in the Zope 3 changelog.
3.2.0 (2006-01-05)
------------------
- Corresponds to the verison of the zope.security package shipped as part of
the Zope 3.2.0 release.
- Removed deprecated helper functions, 'proxy.trustedRemoveSecurityProxy' and
'proxy.getProxiedObject'.
- Made handling of 'management.{end,restore}Interaction' more careful w.r.t.
edge cases.
- Made behavior of 'canWrite' consistent with 'canAccess': if 'canAccess'
does not raise 'ForbiddenAttribute', then neither will 'canWrite'. See:
http://www.zope.org/Collectors/Zope3-dev/506
- Code style / documentation / test fixes.
3.1.0 (2005-10-03)
------------------
- Added support for use of the new Python 2.4 datatypes, 'set' and
'frozenset', within checked code.
- C security proxy acquired a dependency on the 'proxy.h' header from the
'zope.proxy' package.
- XXX: the spelling of the '#include' is bizarre! It seems to be related to
'zpkg'-based builds, and should likely be revisited. For the moment, I have
linked in the 'zope.proxy' package into our own 'include' directory. See
the subversion checkin: http://svn.zope.org/Zope3/?rev=37882&view=rev
- Updated checker to avoid re-proxying objects which have and explicit
'__Security_checker__' assigned.
- Corresponds to the verison of the zope.security package shipped as part of
the Zope 3.1.0 release.
- Clarified contract of 'IChecker' to indicate that its 'check*' methods may
raise only 'Forbidden' or 'Unauthorized' exceptions.
- Added interfaces, ('IPrincipal', 'IGroupAwarePrincipal', 'IGroup', and
'IPermission') specifying contracts of components in the security framework.
- Code style / documentation / test fixes.
3.0.0 (2004-11-07)
------------------
- Corresponds to the version of the zope.security package shipped as part of
the Zope X3.0.0 release.
Keywords: zope security policy principal permission
Platform: UNKNOWN
Classifier: Development Status :: 5 - Production/Stable
Classifier: Environment :: Web Environment
Classifier: Intended Audience :: Developers
Classifier: License :: OSI Approved :: Zope Public License
Classifier: Programming Language :: Python
Classifier: Natural Language :: English
Classifier: Operating System :: OS Independent
Classifier: Topic :: Internet :: WWW/HTTP
Classifier: Framework :: Zope3
|