The filename_trans code had a bug where duplicate detection was being
done between the unmapped type value of a new rule and the type value of rules already in policy. This meant that duplicates were not being silently dropped and were instead outputting a message that there was a problem. It made things hard because the message WAS using the mapped type to convert to the string representation, so it didn't look like a dup!
This commit is contained in:
parent
07e78442e3
commit
878dae3299
@ -0,0 +1,49 @@
|
||||
diff --git a/libsepol/src/expand.c b/libsepol/src/expand.c
|
||||
index 2861776..493e478 100644
|
||||
--- a/libsepol/src/expand.c
|
||||
+++ b/libsepol/src/expand.c
|
||||
@@ -1329,6 +1329,8 @@ static int expand_filename_trans(expand_state_t *state, filename_trans_rule_t *r
|
||||
|
||||
cur_rule = rules;
|
||||
while (cur_rule) {
|
||||
+ uint32_t mapped_otype;
|
||||
+
|
||||
ebitmap_init(&stypes);
|
||||
ebitmap_init(&ttypes);
|
||||
|
||||
@@ -1344,6 +1346,8 @@ static int expand_filename_trans(expand_state_t *state, filename_trans_rule_t *r
|
||||
return -1;
|
||||
}
|
||||
|
||||
+ mapped_otype = state->typemap[cur_rule->otype - 1];
|
||||
+
|
||||
ebitmap_for_each_bit(&stypes, snode, i) {
|
||||
if (!ebitmap_node_get_bit(snode, i))
|
||||
continue;
|
||||
@@ -1358,7 +1362,7 @@ static int expand_filename_trans(expand_state_t *state, filename_trans_rule_t *r
|
||||
(cur_trans->tclass == cur_rule->tclass) &&
|
||||
(!strcmp(cur_trans->name, cur_rule->name))) {
|
||||
/* duplicate rule, who cares */
|
||||
- if (cur_trans->otype == cur_rule->otype)
|
||||
+ if (cur_trans->otype == mapped_otype)
|
||||
break;
|
||||
|
||||
ERR(state->handle, "Conflicting filename trans rules %s %s %s : %s otype1:%s otype2:%s",
|
||||
@@ -1367,7 +1371,7 @@ static int expand_filename_trans(expand_state_t *state, filename_trans_rule_t *r
|
||||
state->out->p_type_val_to_name[j],
|
||||
state->out->p_class_val_to_name[cur_trans->tclass - 1],
|
||||
state->out->p_type_val_to_name[cur_trans->otype - 1],
|
||||
- state->out->p_type_val_to_name[state->typemap[cur_rule->otype - 1] - 1]);
|
||||
+ state->out->p_type_val_to_name[mapped_otype - 1]);
|
||||
|
||||
return -1;
|
||||
}
|
||||
@@ -1397,7 +1401,7 @@ static int expand_filename_trans(expand_state_t *state, filename_trans_rule_t *r
|
||||
new_trans->stype = i + 1;
|
||||
new_trans->ttype = j + 1;
|
||||
new_trans->tclass = cur_rule->tclass;
|
||||
- new_trans->otype = state->typemap[cur_rule->otype - 1];
|
||||
+ new_trans->otype = mapped_otype;
|
||||
}
|
||||
}
|
||||
|
@ -1,10 +1,11 @@
|
||||
Summary: SELinux binary policy manipulation library
|
||||
Name: libsepol
|
||||
Version: 2.1.3
|
||||
Release: 1%{?dist}
|
||||
Release: 2%{?dist}
|
||||
License: LGPLv2+
|
||||
Group: System Environment/Libraries
|
||||
Source: http://www.nsa.gov/selinux/archives/libsepol-%{version}.tgz
|
||||
Patch: libsepol-rhat.patch
|
||||
URL: http://www.selinuxproject.org
|
||||
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
|
||||
|
||||
@ -44,6 +45,8 @@ needed for developing applications that manipulate binary policies.
|
||||
|
||||
%prep
|
||||
%setup -q
|
||||
%patch -p2 -b .rhat
|
||||
|
||||
# sparc64 is an -fPIC arch, so we need to fix it here
|
||||
%ifarch sparc64
|
||||
sed -i 's/fpic/fPIC/g' src/Makefile
|
||||
@ -96,6 +99,15 @@ exit 0
|
||||
/%{_lib}/libsepol.so.1
|
||||
|
||||
%changelog
|
||||
* Mon Oct 31 2011 Dan Walsh <dwalsh@redhat.com> - 2.1.3-2
|
||||
-The filename_trans code had a bug where duplicate detection was being
|
||||
done between the unmapped type value of a new rule and the type value of
|
||||
rules already in policy. This meant that duplicates were not being
|
||||
silently dropped and were instead outputting a message that there was a
|
||||
problem. It made things hard because the message WAS using the mapped
|
||||
type to convert to the string representation, so it didn't look like a
|
||||
dup!
|
||||
|
||||
* Mon Sep 19 2011 Dan Walsh <dwalsh@redhat.com> - 2.1.3-1
|
||||
-Update to upstream
|
||||
* Skip writing role attributes for policy.X and
|
||||
|
Loading…
Reference in New Issue
Block a user