[apparmor] [patch] backport python3 compability patch to 2.8 branch
Hello,
I'd like to propose the python3 compability changes from trunk r2052 to
the 2.8 branch.
Most of trunk r2052 also applies to the 2.8 branch. The only difference
is one part for utils/vim/create-apparmor.vim.py:
Trunk r2052 has:
create-apparmor.vim.py
@@ -164,16 +163,16 @@
regex = "@@(" + "|".join(aa_regex_map) + ")@@"
-print '" generated from apparmor.vim.in by create-apparmor.vim.py'
-print '" do not edit this file - edit apparmor.vim.in or
create-apparmor.vim.py instead' + "\n"
+sys.stdout.write('" generated from apparmor.vim.in by
create-apparmor.vim.py\n')
+sys.stdout.write('" do not edit this file - edit apparmor.vim.in or
create-apparmor.vim.py instead' + "\n\n")
-with file("apparmor.vim.in") as template:
+with open("apparmor.vim.in") as template:
for line in template:
line = re.sub(regex, my_repl, line.rstrip())
-print line
-
-print "\n\n\n"
-
-print '" file rules added with create_file_rule()'
-print re.sub(regex, my_repl, filerule)
+sys.stdout.write('%s\n' % line)
+
+sys.stdout.write("\n\n\n\n")
+
+sys.stdout.write('" file rules added with create_file_rule()\n')
+sys.stdout.write(re.sub(regex, my_repl, filerule)+'\n')
The patch I'm proposing just has
create-apparmor.vim.py
@@ -113,7 +112,8 @@ def my_repl(matchobj):
regex = "@@(" + "|".join(aa_regex_map) + ")@@"
-with file("apparmor.vim.in") as template:
+with open("apparmor.vim.in") as template:
for line in template:
line = re.sub(regex, my_repl, line.rstrip())
-print line
+sys.stdout.write('%s\n' % line)
+#print line
See the attachment for the full patch.
Regards,
Christian Boltz
--
the issue has been fixed and everybody moved on to breaking
other stuff :) [Dominique Leuenberger in opensuse-factory]
=== modified file 'common/Make.rules'
Index: common/Make.rules
===
--- common/Make.rules.orig 2012-06-30 01:42:39.0 +0200
+++ common/Make.rules 2013-05-05 18:13:56.759020320 +0200
@@ -32,6 +32,10 @@ ifndef AWK
$(error awk utility required for build but not available)
endif
+# Convenience functions
+pathsearch = $(firstword $(wildcard $(addsuffix /$(1),$(subst :, ,$(PATH)
+map = $(foreach a,$(2),$(call $(1),$(a)))
+
# OVERRIDABLE variables
# Set these variables before including Make.rules to change its behavior
# SPECFILE - for packages that have a non-standard specfile name
@@ -132,6 +136,17 @@ endif
endif
+ifndef PYTHON_VERSIONS
+PYTHON_VERSIONS = $(call map, pathsearch, python2 python3)
+endif
+
+ifndef PYTHON
+PYTHON = $(firstword ${PYTHON_VERSIONS})
+endif
+
+#Helper function to be used with $(call pyalldo, run_test_with_all.py)
+pyalldo=set -e; $(foreach py, $(PYTHON_VERSIONS), $(py) $(1);)
+
.PHONY: version
.SILENT: version
version:
Index: libraries/libapparmor/m4/ac_python_devel.m4
===
--- libraries/libapparmor/m4/ac_python_devel.m4.orig 2012-04-25 21:15:19.0 +0200
+++ libraries/libapparmor/m4/ac_python_devel.m4 2013-05-05 18:13:56.759020320 +0200
@@ -17,9 +17,9 @@ AC_DEFUN([AC_PYTHON_DEVEL],[
# Check for a version of Python >= 2.1.0
#
AC_MSG_CHECKING([for a version of Python >= '2.1.0'])
-ac_supports_python_ver=`$PYTHON -c "import sys, string; \
-ver = string.split(sys.version)[[0]]; \
-print ver >= '2.1.0'"`
+ac_supports_python_ver=`$PYTHON -c "import sys; \
+ver = sys.version.split()[[0]]; \
+sys.stdout.write(str(ver >= '2.1.0'))"`
if test "$ac_supports_python_ver" != "True"; then
if test -z "$PYTHON_NOVERSIONCHECK"; then
AC_MSG_RESULT([no])
@@ -44,9 +44,9 @@ to something else than an empty string.
#
if test -n "$1"; then
AC_MSG_CHECKING([for a version of Python $1])
-ac_supports_python_ver=`$PYTHON -c "import sys, string; \
-ver = string.split(sys.version)[[0]]; \
-print ver $1"`
+ac_supports_python_ver=`$PYTHON -c "import sys; \
+ver = sys.version.split()[[0]]; \
+sys.stdout.write("%s\n" % (ver == $1))"`
if test "$ac_supports_python_ver" = "True"; then
AC_MSG_RESULT([yes])
else
@@ -80,8 +80,8 @@ $ac_distutils_result])
#
AC_MSG_CHECKING([for Python include path])
if test -z "$PYTHON_CPPFLAGS"; then
-python_path=`$PYTHON -c "import distutils.sysconfig; \
-print distutils.sysconfig.get_python_inc();"`
+python_path=`$PYTHON -c "import sys; import distutils.sysconfig;\
+sys.stdout.write('%s\n' % distutils.sysconfig.get_python_inc());"`
if test -n "${python_path}"; then
python_path="-I$pyth
Re: [apparmor] [patch] backport python3 compability patch to 2.8 branch
On Mon, May 06, 2013 at 11:54:58PM +0200, Christian Boltz wrote:
> Hello,
>
> I'd like to propose the python3 compability changes from trunk r2052 to
> the 2.8 branch.
>
> Most of trunk r2052 also applies to the 2.8 branch. The only difference
> is one part for utils/vim/create-apparmor.vim.py:
I don't know the details of Python 3.x migration, nor how to keep
software working with both, but the only thing in here I spotted that
seemed out of place was the commented line below:
> -with file("apparmor.vim.in") as template:
> +with open("apparmor.vim.in") as template:
> for line in template:
> line = re.sub(regex, my_repl, line.rstrip())
> -print line
> +sys.stdout.write('%s\n' % line)
> +#print line
This comment could be deleted.
So feel free to add Skimmed-by: Seth Arnold
or whatever says I didn't spot anything wrong but I also didn't
understand the finer points of what I've read. :)
Thanks
signature.asc
Description: Digital signature
--
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/apparmor
Re: [apparmor] [patch] backport python3 compability patch to 2.8 branch
On 05/06/2013 02:54 PM, Christian Boltz wrote:
> Hello,
>
> I'd like to propose the python3 compability changes from trunk r2052 to
> the 2.8 branch.
>
> Most of trunk r2052 also applies to the 2.8 branch. The only difference
> is one part for utils/vim/create-apparmor.vim.py:
>
I wish the patch was smaller but I think having python 3.0 support in 2.8
is important.
It looks good on my quick read so
Acked-by: John Johansen
> Trunk r2052 has:
> create-apparmor.vim.py
> @@ -164,16 +163,16 @@
>
> regex = "@@(" + "|".join(aa_regex_map) + ")@@"
>
> -print '" generated from apparmor.vim.in by create-apparmor.vim.py'
> -print '" do not edit this file - edit apparmor.vim.in or
> create-apparmor.vim.py instead' + "\n"
> +sys.stdout.write('" generated from apparmor.vim.in by
> create-apparmor.vim.py\n')
> +sys.stdout.write('" do not edit this file - edit apparmor.vim.in or
> create-apparmor.vim.py instead' + "\n\n")
>
> -with file("apparmor.vim.in") as template:
> +with open("apparmor.vim.in") as template:
> for line in template:
> line = re.sub(regex, my_repl, line.rstrip())
> -print line
> -
> -print "\n\n\n"
> -
> -print '" file rules added with create_file_rule()'
> -print re.sub(regex, my_repl, filerule)
> +sys.stdout.write('%s\n' % line)
> +
> +sys.stdout.write("\n\n\n\n")
> +
> +sys.stdout.write('" file rules added with create_file_rule()\n')
> +sys.stdout.write(re.sub(regex, my_repl, filerule)+'\n')
>
>
> The patch I'm proposing just has
> create-apparmor.vim.py
> @@ -113,7 +112,8 @@ def my_repl(matchobj):
>
> regex = "@@(" + "|".join(aa_regex_map) + ")@@"
>
> -with file("apparmor.vim.in") as template:
> +with open("apparmor.vim.in") as template:
> for line in template:
> line = re.sub(regex, my_repl, line.rstrip())
> -print line
> +sys.stdout.write('%s\n' % line)
> +#print line
>
>
> See the attachment for the full patch.
>
>
> Regards,
>
> Christian Boltz
>
>
>
--
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/apparmor
[apparmor] GSoC 2013, Kaan Özdinçer's proposal
I recently read Kaan's proposal for the Google Summer of Code, and thought I should give him my feedback, as I did for Kshitij. First, welcome Kaan. :) > Timeline > > Read AppArmor documentation. Before Jun 17 > Work on mentor's suggestions. Before Jun 17 > Read aa-logprof and aa-genprof documentation Before Jun 17 > Doing analysis on the interaction of rules within a profile as > well as how profiles interact. 1-2 weeks Depending upon how well your first few profiling experiments go, this may not take an entire two weeks; moving rules between a profile and an abstraction is pretty straight forward. We don't often use the 'x' domain transitions in abstractions, and limited the amount of write access is given in abstractions, just to make understanding profiles a little easier. I think we will continue to keep some of these guidelines in mind -- putting domain transition 'x' rules in abstractions is a bit like a non-local 'goto' in one function that can jump to the middle of another function. (The analogy is certainly not perfect, but .. gives a good feeling for what I think of the more complicated rule possibilities.) > Doing static analysis on applications to extract possible rules > and rule patterns. 1-2 weeks Is this analysis on applications or on application profiles? > Creating a tool to merge multiple profiles together. 2 weeks This is probably very optimistic. For simple cases, it might be suitable, but profiles with different P/U/i X decisions, or different child profiles, I think two weeks may be just sufficient to figure out what the UI should look like. Actually doing it will probably take longer. > Developing a better interface that will aid the user in being able > to find abstractions, and analyze inter-profile behavior. 2 weeks This also feels optimistic. I could imagine something 'easy' being done in two weeks, but I do not know if the results would be useful enough to rely upon it. I'd love to be wrong here, though. :) > Update the existing YaST module to interface with the new profile > development tool. 2 weeks This is definitely too little time. Consider making this one an optional addition. > Announce them to community for review and getting contribution. > Last 3 weeks > Writing documentation. Last 1-2 weeks Seems fair :) > Technical details > > Doing analysis on the interaction of rules within a profile as > well as how profiles interact. This can be used to simplify rules, > suggest simplifications or abstrations, and discover potential > security holes in the provided policy. Very much looking forward to this. > Creating a tool to merge multiple profiles together. Working > similar to logprof, but using profiles instead of a log as input. Also this. :) > Developing a better interface that will aid the user in being able > to find abstractions, and analyze inter-profile behavior. Yay! > Update the existing YaST module to interface with the new profile > development tool. Existing YaST module code is truly gruesome. It had to meet some fairly arbitrary constraints that made sense at the time but do not make sense now. Also, the whole thing is written in Perl, and we'd very much like new tools to be in Python. I don't know if YaST makes Python modules easy, but I wouldn't pick our module as the starting point... What feels like it is missing from this list is a logprof / genprof replacement: authoring policies from ALLOWED or DENIED log entries. Our existing tools are no longer maintainable and trying to add the cool new features you've proposed here to the existing tools would be an exercise in frustration and futility. This is a truly unfortunate situation, since the cool new features are definitely cooler and more fun to work on. But without a reasonably reliable and stable base to build from, the cool tools are going to be out of reach in a very frustrating sort of way. So, if you've got the time to revise the proposal, please consider setting aside more time for a tool for profile development from log files, and perhaps doing so at the expense of the YaST module or application analysis. Thanks, and welcome :) signature.asc Description: Digital signature -- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
[apparmor] do any of you know anything about AppArmor and creating and long term maintaining/improving profiles for Tor and Tor Browser would help a lot.
do any you know anything about AppArmor and creating and long term maintaining/improving profiles for Tor and Tor Browser would help a lot. thanks. -- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
Re: [apparmor] [patch] backport python3 compability patch to 2.8 branch
On Mon, May 06, 2013 at 11:54:58PM +0200, Christian Boltz wrote: > Hello, > > I'd like to propose the python3 compability changes from trunk r2052 to > the 2.8 branch. > > Most of trunk r2052 also applies to the 2.8 branch. The only difference > is one part for utils/vim/create-apparmor.vim.py: Acked-by: Steve Beattie You probably also want to pull in trunk commit 2108 as well. -- Steve Beattie http://NxNW.org/~steve/ signature.asc Description: Digital signature -- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
