[patch 0/3] genhomedircon replacement in libsemanage

[patch 0/3] genhomedircon replacement in libsemanage

[jbrindle]

This replaces genhomedircon with equivalent functionality in libsemanage. The homedir_template is also no longer installed, this leaves some unused path functions in libselinux but removing those would break the ABI. 

This does the same things that genhomedircon did though some seemed strange, like removing /sbin/nologin from the list of valid shells, presumably to keep ftp users and such from getting file contexts generated for them, I'm not sure how valid the assumption is but we didn't want to change the functionality of genhomedircon in this patch set.

The first patch adds genhomedircon.c to libsemanage and calls it from the semanage_store.c and removes the prior call to genhomedircon.

The second patch is a set of tests for the new functions

And the third patch removes the old genhomedircon script.


Signed-Off-By: Joshua Brindle <jbrindle@tresys.com>

-- 

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

[patch 1/3] libsemanage: genhomedircon replacement

[jbrindle]

Remove python script genhomedircon from libsemanage and replace
with C functionality.

Index: ghdc/libsemanage/src/genhomedircon.c
===================================================================
--- /dev/null
+++ ghdc/libsemanage/src/genhomedircon.c
@@ -0,0 +1,590 @@
+/* Author: Mark Goldman   <mgoldman@tresys.com>
+ *
+ * Copyright (C) 2007 Tresys Technology, LLC
+ *
+ *  This library is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU Lesser General Public License as
+ *  published by the Free Software Foundation; either version 2.1 of the
+ *  License, or (at your option) any later version.
+ *
+ *  This library is distributed in the hope that it will be useful, but
+ *  WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ *  Lesser General Public License for more details.
+ *
+ *  You should have received a copy of the GNU Lesser General Public
+ *  License along with this library; if not, write to the Free Software
+ *  Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ *  02110-1301  USA
+ */
+#include <assert.h>
+#include <limits.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <sys/types.h>
+#include <sys/stat.h>
+#include <fcntl.h>
+#include <pwd.h>
+
+#include <semanage/handle.h>
+#include <semanage/seusers_policy.h>
+#include <semanage/users_policy.h>
+#include <semanage/user_record.h>
+#include "semanage_store.h"
+#include "seuser_internal.h"
+#include "debug.h"
+
+#include "utilities.h"
+#include "genhomedircon.h"
+
+static int fwriteoutput(state_t * s, FILE * out);
+
+/* should default to usepasswd */
+int semanage_genhomedircon(semanage_handle_t * sh, int usepasswd)
+{
+	state_t s;
+
+	char outfile[PATH_MAX];
+	char hdt[PATH_MAX];
+	char fcf[PATH_MAX];
+
+	FILE *out = NULL;
+	int retval = 0;
+
+	assert(sh);
+
+	s.homedir_template_path = hdt;
+	snprintf(s.homedir_template_path, PATH_MAX - 1, "%s",
+		 semanage_path(SEMANAGE_TMP, SEMANAGE_HOMEDIR_TMPL));
+
+	snprintf(outfile, PATH_MAX - 1, "%s",
+		 semanage_path(SEMANAGE_TMP, SEMANAGE_FC_HOMEDIRS));
+
+	s.fcfilepath = fcf;
+
+	snprintf(s.fcfilepath, PATH_MAX - 1, "%s",
+		 semanage_path(SEMANAGE_TMP, SEMANAGE_FC_HOMEDIRS));
+
+	s.usepasswd = usepasswd;
+	s.h_semanage = sh;
+
+	if (!(out = fopen(s.fcfilepath, "w"))) {
+		/* couldn't open output file */
+		ERR(sh, "Could not open the file_context file for writing");
+		retval = STATUS_ERR;
+		goto out;
+	}
+
+	fwriteoutput(&s, out);
+
+      out:
+	fclose(out);
+	return retval;
+}
+
+static list_t *default_shell_list(void)
+{
+	list_t *list = NULL;
+	semanage_list_push(&list, "/bin/csh");
+	semanage_list_push(&list, "/bin/tcsh");
+	semanage_list_push(&list, "/bin/ksh");
+	semanage_list_push(&list, "/bin/bsh");
+	semanage_list_push(&list, "/bin/ash");
+	semanage_list_push(&list, "/usr/bin/ksh");
+	semanage_list_push(&list, "/usr/bin/pdksh");
+	semanage_list_push(&list, "/bin/zsh");
+	semanage_list_push(&list, "/bin/sh");
+	semanage_list_push(&list, "/bin/bash");
+	return list;
+}
+
+static list_t *get_shell_list(void)
+{
+	FILE *shells;
+	char *temp = NULL;
+	list_t *list = NULL;
+
+	shells = fopen("/etc/shells", "r");
+	if (!shells)
+		return default_shell_list();
+	while ((temp = semanage_fgetline(shells))) {
+		if (!strcmp(temp, "/sbin/nologin")) {
+			free(temp);
+			continue;
+		}
+		semanage_list_push(&list, temp);
+		free(temp);
+	}
+	return list;
+}
+
+static list_t *get_home_dirs(state_t * s)
+{
+	list_t *l = NULL;
+	list_t *shells = NULL;
+	char *path;
+	size_t minuid = 2000000;	/* sentinal value, UIDs can't be
+					 * above ~64k */
+	size_t temp;
+	struct passwd *pwbuf;
+	struct stat buf;
+
+	path = semanage_findval("/etc/default/useradd", "HOME", "=");
+	if (path && *path) {
+		semanage_list_push(&l, path);
+	}
+	free(path);
+
+	path = semanage_findval("/etc/libuser.conf", "LU_HOMEDIRECTORY", "=");
+	if (path && *path) {
+		semanage_list_push(&l, path);
+	}
+	free(path);
+
+	if (!l)
+		semanage_list_push(&l, strdup("/home"));
+
+	if (!stat("/export/home", &buf)) {
+		if (buf.st_mode | S_IFDIR)
+			semanage_list_push(&l, strdup("/export/home"));
+	}
+
+	if (!(s->usepasswd))
+		return l;
+
+	path = semanage_findval("/etc/login.defs", "UID_MIN", NULL);
+	if (path && *path) {
+		temp = atoi(path);
+		if (temp < minuid)
+			minuid = temp;
+	}
+	free(path);
+
+	path = semanage_findval("/etc/libuser.conf", "LU_UIDNUMBER", "=");
+	if (path && *path) {
+		temp = atoi(path);
+		if (temp < minuid)
+			minuid = temp;
+	}
+	free(path);
+
+	if (minuid == 2000000)
+		minuid = 500;
+
+	shells = get_shell_list();
+
+	setpwent();
+	while ((pwbuf = getpwent())) {
+		if (pwbuf->pw_uid < minuid)
+			continue;
+		if (!semanage_list_find(shells, pwbuf->pw_shell))
+			continue;
+		if (strcmp(pwbuf->pw_dir, "/") == 0)
+			continue;
+		if (semanage_str_count(pwbuf->pw_dir, '/') <= 1)
+			continue;
+		path = strdup(pwbuf->pw_dir);
+		semanage_rtrim(path, '/');
+		if (!semanage_list_find(l, path)) {
+			semanage_list_push(&l, path);	
+		}
+		free(path);
+	}
+
+	/* clean up: I'm returning l so I don't need to do anything with it.
+	 *           I free the memory pointed to by path as soon as I'm done.
+	 *           That leaves the shells list which I destoy here.
+	 */
+	endpwent();
+	semanage_list_destroy(&shells);
+
+	semanage_list_sort(&l);
+	return l;
+}
+
+/**
+ * @param	s	state structure, stores various paths etc. Must never be NULL
+ * @param	out	the FILE to put all the output in.
+ * @return	0 on success
+ */
+static int fwriteheader(state_t * s, FILE * out)
+{
+
+	fprintf(out,
+		"#\n#\n# User-specific file contexts, generated via libsemanage\n");
+	fprintf(out,
+		"# use semanage command to manage system users to change the"
+		" file_context\n#\n#\n");
+	return 0;
+}
+
+/* Predicates for use with semanage_slurp_file_filter() the homedir_template file
+ * currently contains lines that serve as the template for a user's
+ * homedir.
+ *
+ * It also contains lines that are the template for the parent of a
+ * user's home directory.
+ *
+ * Currently, the only lines that apply to the the root of a user's home
+ * directory are all prefixed with the string "HOME_ROOT".  All other
+ * lines apply to a user's home directory.  If this changes the
+ * following predicates need to change to reflect that.
+ */
+static int HOME_ROOT_PRED(char *string)
+{
+	return semanage_prefix_of(string, "HOME_ROOT");
+}
+
+static int HOME_DIR_PRED(char *string)
+{
+	return semanage_prefix_of(string, "HOME_DIR");
+}
+
+static int USER_CONTEXT_PRED(char *string)
+{
+	return (int)(strstr(string, "USER") != NULL);
+}
+
+/* make_home_dir_tempate
+ * make_home_root_template
+ * @param	s	  the state holding the paths to various files
+ * @return   a list of lines from the template file with inappropriate
+ *	    lines filtered out.
+ */
+static list_t *make_home_dir_template(state_t * s)
+{
+	FILE *template_file = NULL;
+	list_t *template_data = NULL;
+
+	template_file = fopen(s->homedir_template_path, "r");
+	if (!template_file)
+		return NULL;
+	template_data = semanage_slurp_file_filter(template_file, &HOME_DIR_PRED);
+	fclose(template_file);
+	return template_data;
+}
+
+static list_t *make_home_root_template(state_t * s)
+{
+	FILE *template_file = NULL;
+	list_t *template_data = NULL;
+
+	template_file = fopen(s->homedir_template_path, "r");
+	if (!template_file)
+		return NULL;
+	template_data = semanage_slurp_file_filter(template_file, &HOME_ROOT_PRED);
+	fclose(template_file);
+	return template_data;
+}
+
+static list_t *make_user_context_template(state_t * s)
+{
+	FILE *template_file = NULL;
+	list_t *template_data = NULL;
+
+	template_file = fopen(s->homedir_template_path, "r");
+	if (!template_file)
+		return NULL;
+	template_data = semanage_slurp_file_filter(template_file, &USER_CONTEXT_PRED);
+	fclose(template_file);
+	return template_data;
+}
+
+static int write_home_dir_context(FILE * out, list_t * tpl, char *user,
+				  char *seuser, char *home, char *prefix)
+{
+	char *temp;
+	char *line;
+
+	fprintf(out, "\n\n#\n# Home Context for user %s\n#\n\n", user);
+	for (; tpl; tpl = tpl->next) {
+		temp = semanage_sed(tpl->data, "HOME_DIR", home);
+		if (!temp)
+			return -1;
+		line = temp;
+		temp = semanage_sed(line, "ROLE", prefix);
+		free(line);
+		if (!temp)
+			return -1;
+		line = temp;
+		temp = semanage_sed(line, "system_u", seuser);
+		free(line);
+		if (!temp)
+			return -1;
+		line = temp;
+		fputs(line, out);
+		fputs("\n", out);
+		free(line);
+	}
+	return 0;
+}
+
+static int write_home_root_context(FILE * out, list_t * tpl, char *homedir)
+{
+	char *temp;
+
+	for (; tpl; tpl = tpl->next) {
+		temp = semanage_sed(tpl->data, "HOME_ROOT", homedir);
+		if (!temp)
+			return -1;
+		fputs(temp, out);
+		fputs("\n", out);
+		free(temp);
+	}
+	return 0;
+}
+
+static int write_user_context(FILE * out, list_t * tpl, char *user,
+			      char *seuser, char *prefix)
+{
+	char *temp;
+	char *line;
+
+	for (; tpl; tpl = tpl->next) {
+		temp = semanage_sed(tpl->data, "USER", user);
+		if (!temp)
+			return -1;
+		line = temp;
+		temp = semanage_sed(line, "ROLE", prefix);
+		free(line);
+		if (!temp)
+			return -1;
+		line = temp;
+		temp = semanage_sed(line, "system_u", seuser);
+		free(line);
+		if (!temp)
+			return -1;
+		line = temp;
+		fputs(line, out);
+		fputs("\n", out);
+		free(line);
+	}
+	return 0;
+}
+
+static int user_sort_func(semanage_user_t ** arg1, semanage_user_t ** arg2)
+{
+	return strcmp(semanage_user_get_name(*arg1),
+		      semanage_user_get_name(*arg2));
+}
+
+static int name_user_cmp(char *key, semanage_user_t ** val)
+{
+	int ret = strcmp(key, semanage_user_get_name(*val));
+	return ret;
+}
+
+static int push_user_entry(user_entry_t ** list, const char *n, const char *sen,
+			   const char *pre, const char *h)
+{
+	user_entry_t *temp = NULL;
+	char *name = NULL;
+	char *sename = NULL;
+	char *prefix = NULL;
+	char *home = NULL;
+
+	temp = malloc(sizeof(user_entry_t));
+	if (!temp)
+		goto cleanup;
+	name = strdup(n);
+	if (!name)
+		goto cleanup;
+	sename = strdup(sen);
+	if (!sename)
+		goto cleanup;
+	prefix = strdup(pre);
+	if (!prefix)
+		goto cleanup;
+	home = strdup(h);
+	if (!home)
+		goto cleanup;
+
+	temp->name = name;
+	temp->sename = sename;
+	temp->prefix = prefix;
+	temp->home = home;
+	temp->next = (*list);
+	(*list) = temp;
+
+	return 0;
+
+      cleanup:
+	free(name);
+	free(sename);
+	free(prefix);
+	free(home);
+	free(temp);
+	return -1;
+}
+
+static void pop_user_entry(user_entry_t ** list)
+{
+	user_entry_t *temp;
+
+	if (!list || !(*list))
+		return;
+	temp = *list;
+	*list = temp->next;
+	free(temp->name);
+	free(temp->sename);
+	free(temp->prefix);
+	free(temp->home);
+	free(temp);
+	return;
+}
+
+static user_entry_t *get_users(state_t * s)
+{
+	user_entry_t *head = NULL;
+
+	semanage_seuser_t **seuser_list = NULL;
+	unsigned int nseusers = 0;
+
+	semanage_user_t **user_list = NULL;
+	unsigned int nusers = 0;
+
+	semanage_user_t **u = NULL;
+	const char *name = NULL;
+	const char *seuname = NULL;
+	const char *prefix = NULL;
+
+	struct passwd *pwent = NULL;
+
+	unsigned int i;
+	int retval;
+
+	if ((retval =
+	     semanage_seuser_list(s->h_semanage, &seuser_list, &nseusers) < 0)
+	    || (nseusers < 1)) {
+		/* if there are no users, this function can't do any other work */
+		return NULL;
+	}
+
+	if (semanage_user_list(s->h_semanage, &user_list, &nusers) < 0) {
+		nusers = 0;
+	}
+
+	qsort(user_list, nusers, sizeof(semanage_user_t *),
+	      (int (*)(const void *, const void *))&user_sort_func);
+
+	for (i = 0; i < nseusers; i++) {
+		name = semanage_seuser_get_name(seuser_list[i]);
+		seuname = semanage_seuser_get_sename(seuser_list[i]);
+
+		if (strcmp(seuname, "user_u") == 0)
+			continue;
+		if (strcmp(seuname, "__default__") == 0)
+			continue;
+		if (strcmp(seuname, "system_u") == 0)
+			continue;
+
+		/* find the user structure givent the name */
+		u = bsearch(name, user_list, nusers, sizeof(semanage_user_t *),
+			    (int (*)(const void *, const void *))
+			    &name_user_cmp);
+		if (u) {
+			prefix = semanage_user_get_prefix(*u);
+		} else {
+			prefix = name;
+		}
+
+		pwent = getpwnam(name);
+		if (!pwent) {
+			/* user not in passwd file, genhomedircon
+			 * printed a message here */
+			continue;
+		}
+
+		if (strcmp(pwent->pw_dir, "/") == 0) {
+			/* don't relabel / genhomdircon checked to see if root
+			 * was the user and if so, set his home directory to
+			 * /root */
+			continue;
+		}
+
+		push_user_entry(&head, name, seuname, prefix, pwent->pw_dir);
+	}
+	for (i = 0; i < nseusers; i++) {
+		semanage_seuser_free(seuser_list[i]);
+	}
+	free(seuser_list);
+
+	for (i = 0; i < nusers; i++) {
+		semanage_user_free(user_list[i]);
+	}
+	free(user_list);
+	return head;
+}
+
+static int write_gen_home_dir_context(FILE * out, state_t * s,
+				      list_t * user_context_tpl,
+				      list_t * homedir_context_tpl)
+{
+	user_entry_t *users;
+
+	for (users = get_users(s); users; pop_user_entry(&users)) {
+		write_home_dir_context(out, homedir_context_tpl,
+				       users->name,
+				       users->sename, users->home,
+				       users->prefix);
+		write_user_context(out, user_context_tpl, users->name,
+				   users->sename, users->prefix);
+	}
+	return 0;
+}
+
+/**
+ * @param	s	state structure, stores various paths etc. Must never be NULL
+ * @param	out	the FILE to put all the output in.
+ * @return	0 on success
+ */
+static int fwriteoutput(state_t * s, FILE * out)
+{
+	list_t *homedirs = NULL;
+	list_t *h = NULL;
+	list_t *user_context_tpl = NULL;
+	list_t *homedir_context_tpl = NULL;
+	list_t *homeroot_context_tpl = NULL;
+
+	char *temp;
+	int s1len;
+
+	homedirs = get_home_dirs(s);
+	if (!homedirs) {
+		WARN(s->h_semanage,
+		     "no home directories were available, exiting without writing");
+		return -1;	/* No homedirs so no output */
+	}
+
+	fwriteheader(s, out);
+
+	homedir_context_tpl = make_home_dir_template(s);
+	homeroot_context_tpl = make_home_root_template(s);
+	user_context_tpl = make_user_context_template(s);
+
+	for (h = homedirs; h; h = h->next) {
+		s1len = strlen(h->data);
+		temp = malloc(s1len + sizeof("/[^/]*"));
+		strcpy(temp, h->data);
+		strcpy(temp + s1len, "/[^/]*");
+
+		write_home_dir_context(out,
+				       homedir_context_tpl, "user_u", "user_u",
+				       temp, "user");
+		write_home_root_context(out, homeroot_context_tpl, h->data);
+
+		free(temp);
+	}
+	write_user_context(out, user_context_tpl, ".*", "user_u", "user");
+	write_gen_home_dir_context(out, s, user_context_tpl,
+				   homedir_context_tpl);
+
+	/* Cleanup */
+	semanage_list_destroy(&homedirs);
+	semanage_list_destroy(&user_context_tpl);
+	semanage_list_destroy(&homedir_context_tpl);
+	semanage_list_destroy(&homeroot_context_tpl);
+
+	return 0;
+}
Index: ghdc/libsemanage/src/genhomedircon.h
===================================================================
--- /dev/null
+++ ghdc/libsemanage/src/genhomedircon.h
@@ -0,0 +1,42 @@
+/* Author: Mark Goldman   <mgoldman@tresys.com>
+ *
+ * Copyright (C) 2007 Tresys Technology, LLC
+ *
+ *  This library is free software; you can redistribute it and/or
+ *  modify it under the terms of the GNU Lesser General Public
+ *  License as published by the Free Software Foundation; either
+ *  version 2.1 of the License, or (at your option) any later version.
+ *
+ *  This library is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ *  Lesser General Public License for more details.
+ *
+ *  You should have received a copy of the GNU Lesser General Public
+ *  License along with this library; if not, write to the Free Software
+ *  Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
+ */
+
+#ifndef selinux_genhomedircon
+#define selinux_genhomedircon
+
+#include "utilities.h"
+
+typedef struct {
+	char *fcfilepath;
+	int usepasswd;
+	char *homedir_template_path;
+	semanage_handle_t *h_semanage;
+} state_t;
+
+typedef struct user_entry {
+	char *name;
+	char *sename;
+	char *prefix;
+	char *home;
+	struct user_entry *next;
+} user_entry_t;
+
+int semanage_genhomedircon(semanage_handle_t * sh, int usepasswd);
+
+#endif
Index: ghdc/libsemanage/src/semanage_store.c
===================================================================
--- ghdc.orig/libsemanage/src/semanage_store.c
+++ ghdc/libsemanage/src/semanage_store.c
@@ -34,6 +34,7 @@ typedef struct dbase_policydb dbase_t;
 #include "semanage_store.h"
 #include "database_policydb.h"
 #include "handle.h"
+#include "genhomedircon.h"
 
 #include <selinux/selinux.h>
 #include <sepol/policydb.h>
@@ -110,6 +111,7 @@ static const char *semanage_sandbox_path
 	"/seusers.final",
 	"/users_extra",
 	"/netfilter_contexts",
+	"/file_contexts.homedirs",
 };
 
 /* A node used in a linked list of file contexts; used for sorting.
@@ -1008,14 +1010,15 @@ static int semanage_install_active(seman
 	const char *active_fc = semanage_path(SEMANAGE_ACTIVE, SEMANAGE_FC);
 	const char *active_fc_loc =
 	    semanage_path(SEMANAGE_ACTIVE, SEMANAGE_FC_LOCAL);
-	const char *active_hd =
-	    semanage_path(SEMANAGE_ACTIVE, SEMANAGE_HOMEDIR_TMPL);
 	const char *active_seusers =
 	    semanage_path(SEMANAGE_ACTIVE, SEMANAGE_SEUSERS);
 	const char *active_nc = semanage_path(SEMANAGE_ACTIVE, SEMANAGE_NC);
+	const char *active_fc_hd =
+	    semanage_path(SEMANAGE_ACTIVE, SEMANAGE_FC_HOMEDIRS);
 
 	const char *running_fc = selinux_file_context_path();
 	const char *running_fc_loc = selinux_file_context_local_path();
+	const char *running_fc_hd = selinux_file_context_homedir_path();
 	const char *running_hd = selinux_homedir_context_path();
 	const char *running_policy = selinux_binary_policy_path();
 	const char *running_seusers = selinux_usersconf_path();
@@ -1027,14 +1030,15 @@ static int semanage_install_active(seman
 	 * POLICYTYPE and should probably be done in the future. */
 	char store_fc[PATH_MAX];
 	char store_fc_loc[PATH_MAX];
-	char store_hd[PATH_MAX];
 	char store_pol[PATH_MAX];
 	char store_seusers[PATH_MAX];
 	char store_nc[PATH_MAX];
+	char store_fc_hd[PATH_MAX];
 
 	len = strlen(really_active_store);
 	running_fc += len;
 	running_fc_loc += len;
+	running_fc_hd += len;
 	running_hd += len;
 	running_policy += len;
 	running_seusers += len;
@@ -1055,9 +1059,10 @@ static int semanage_install_active(seman
 		goto cleanup;
 	}
 
-	snprintf(store_hd, PATH_MAX, "%s%s", storepath, running_hd);
-	if (semanage_copy_file(active_hd, store_hd, sh->conf->file_mode) == -1) {
-		ERR(sh, "Could not copy %s to %s.", active_hd, store_hd);
+	snprintf(store_fc_hd, PATH_MAX, "%s%s", storepath, running_fc_hd);
+	if (semanage_copy_file(active_fc_hd, store_fc_hd, sh->conf->file_mode)
+	    == -1) {
+		ERR(sh, "Could not copy %s to %s.", active_fc_hd, store_fc_hd);
 		goto cleanup;
 	}
 
@@ -1197,6 +1202,10 @@ static int semanage_commit_sandbox(seman
 		retval = -1;
 		goto cleanup;
 	}
+
+	/* clean up some files from the sandbox before install */
+	/* remove homedir_template from sandbox */
+
 	if (rename(sandbox, active) == -1) {
 		ERR(sh, "Error while renaming %s to %s.", sandbox, active);
 		/* note that if an error occurs during the next
@@ -1227,7 +1236,8 @@ static int semanage_commit_sandbox(seman
 	if (!sh->conf->save_previous) {
 		retval = semanage_remove_directory(backup);
 		if (retval < 0) {
-			ERR(sh, "Could not delete previous directory %s.", backup);
+			ERR(sh, "Could not delete previous directory %s.",
+			    backup);
 			goto cleanup;
 		}
 	}
@@ -1257,15 +1267,15 @@ int semanage_install_sandbox(semanage_ha
 		goto cleanup;
 	}
 
-	if ((commit_num = semanage_commit_sandbox(sh)) < 0) {
-		retval = commit_num;
+	if ((retval =
+	     semanage_genhomedircon(sh, 1)) != 0) {
+		ERR(sh, "semanage_genhomedircon returned error code %d.",
+		    retval);
 		goto cleanup;
 	}
 
-	if ((retval =
-	     semanage_exec_prog(sh, sh->conf->genhomedircon,
-				sh->conf->store_path, "")) != 0) {
-		ERR(sh, "genhomedircon returned error code %d.", retval);
+	if ((commit_num = semanage_commit_sandbox(sh)) < 0) {
+		retval = commit_num;
 		goto cleanup;
 	}
 
Index: ghdc/libsemanage/src/utilities.c
===================================================================
--- /dev/null
+++ ghdc/libsemanage/src/utilities.c
@@ -0,0 +1,359 @@
+/* Author: Mark Goldman   <mgoldman@tresys.com>
+ *
+ * Copyright (C) 2007 Tresys Technology, LLC
+ *
+ *  This library is free software; you can redistribute it and/or
+ *  modify it under the terms of the GNU Lesser General Public
+ *  License as published by the Free Software Foundation; either
+ *  version 2.1 of the License, or (at your option) any later version.
+ *
+ *  This library is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ *  Lesser General Public License for more details.
+ *
+ *  You should have received a copy of the GNU Lesser General Public
+ *  License along with this library; if not, write to the Free Software
+ *  Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
+ */
+
+#include <stdio.h>
+#include <stdlib.h>
+#include <ctype.h>
+#include <string.h>
+#include <sys/types.h>
+#include <regex.h>
+
+#include "utilities.h"
+
+char *semanage_findval(char *file, char *var, char *delim)
+{
+	FILE *fd;
+
+	char *buff;
+	char *temp = NULL;
+
+	if (!file || !var || !delim)
+		return NULL;
+
+	if ((fd = fopen(file, "r")) == NULL)
+		return NULL;
+
+	while (!feof(fd)) {
+		if (!(buff = semanage_fgetline(fd))){
+			goto err;
+		}
+		if (semanage_prefix_of(buff, var)) {
+			/* Found it */
+			temp = semanage_split(buff, delim);
+			/* if semanage_split succedes dup the token */
+			if (temp != NULL)
+				temp = strdup(temp);
+			free(buff);	/* free the buffer */
+			goto out;
+		}
+		free(buff);	/* free the buffer for next time through the loop */
+	}
+
+err:
+	temp = NULL;
+out:
+	fclose(fd);
+	return temp;
+
+}
+
+int semanage_prefix_of(char *str, char *val)
+{
+	if (!str)
+		return 0;
+	if (!val)
+		return 1;
+
+	while ((*str) && (*val) && (*str == *val)) {
+		++str;
+		++val;
+	}
+
+	return !(*val);
+}
+
+char *semanage_split_on_space(char *str)
+{
+	if (!str)
+		return NULL;
+
+	while ((*str != '\0') && !(isspace(*str)))
+		str++;
+	while ((*str != '\0') && (isspace(*str)))
+		str++;
+
+	return str;
+}
+
+char *semanage_split(char *str, char *delim)
+{
+	char *temp = str;
+
+	if (!str)
+		return NULL;
+	if (!delim || (*delim == '\0'))
+		return semanage_split_on_space(str);
+
+	strsep(&temp, delim);	/* temp gets updated to the char past delim */
+
+	return temp;
+}
+
+char *semanage_fgetline(FILE * f)
+{
+	char *buff;
+	char *tbuff;
+	int size = 256;
+	int current = 0;
+	int ch = 0;
+
+	if (ferror(f)) {
+		return NULL;
+	}
+	if (feof(f))
+		return NULL;	/* nothing left in file so return NULL
+				 * lets us write while(val = semanage_fgetline(f))
+				 * loops */
+	if (!(buff = malloc(size)))
+		return NULL;
+
+	while ((ch = fgetc(f)) != EOF) {
+		if (ch == '\n')
+			break;
+		buff[current++] = ch;
+		if (current >= size) {
+			size *= 2;
+			if (!(tbuff = realloc(buff, size))) {
+				free(buff);
+				return NULL;
+			} else {
+				buff = tbuff;
+			}
+		}
+	}
+
+	buff[current] = '\0';
+	return buff;
+}
+
+int semanage_list_push(list_t ** list, char *data)
+{
+	list_t *temp = malloc(sizeof(list_t));
+	if (!temp)
+		return -1;
+	temp->data = strdup(data);
+	if (!temp->data) {
+		free(temp);
+		return -2;
+	}
+	temp->next = *list;
+	*list = temp;
+	return 0;
+}
+
+char *semanage_list_pop(list_t ** list)
+{
+	list_t *retval;
+	char *data;
+	if (!(*list))
+		return NULL;
+	retval = (*list);
+	(*list) = retval->next;
+	data = retval->data;
+	free(retval);
+	return data;
+}
+
+void semanage_list_destroy(list_t ** list)
+{
+	list_t *temp;
+	while ((temp = (*list))) {
+		free(temp->data);
+		(*list) = temp->next;
+		free(temp);
+	}
+}
+
+/* list_addafter_controlmem does *NOT* duplicate the data argument
+ * use at your own risk, I am building a list out of malloc'd memory and
+ * it is only going to get stored into this list, thus when I destroy it
+ * later I won't free a ptr twice.
+ *
+ * returns the newly created node or NULL on error
+ */
+list_t *list_addafter_controlmem(list_t * item, char *data)
+{
+	list_t *temp = malloc(sizeof(list_t));
+	if (!temp)
+		return NULL;
+	temp->data = data;
+	temp->next = item->next;
+	item->next = temp;
+	return temp;
+}
+
+list_t *semanage_list_find(list_t * l, char *data)
+{
+	if (!data)
+		return 0;
+	while (l && strcmp(l->data, data))
+		l = l->next;
+	return l;
+}
+
+int semanage_list_sort(list_t ** l)
+{
+	list_t **array = NULL;
+	list_t *temp = NULL;
+	size_t count = 0;
+	size_t i = 0;
+
+	if (!l)
+		return 0;
+
+	for (temp = *l; temp; temp = temp->next)
+		++count;
+
+	array = malloc(sizeof(list_t *) * count);
+	if (!array)
+		return -1;	/* couldn't allocate memory for sort */
+	for (temp = *l; temp; temp = temp->next) {
+		array[i++] = temp;
+	}
+
+	qsort(array, count, sizeof(list_t *),
+	      (int (*)(const void *, const void *))&semanage_cmp_plist_t);
+	for (i = 0; i < (count - 1); ++i) {
+		array[i]->next = array[i + 1];
+	}
+	array[i]->next = NULL;
+	(*l) = array[0];
+	free(array);
+	return 0;
+}
+
+int semanage_cmp_plist_t(const list_t ** x, const list_t ** y)
+{
+	return strcmp((*x)->data, (*y)->data);
+}
+
+int semanage_str_count(char *data, char what)
+{
+	int count = 0;
+	if (!data)
+		return 0;
+	while (*data) {
+		if (*data == what)
+			++count;
+		++data;
+	}
+	return count;
+}
+
+void semanage_rtrim(char *str, char trim_to)
+{
+	int len;
+
+	if (!str)
+		return;
+	len = strlen(str);
+
+	while (len > 0) {
+		if (str[--len] == trim_to) {
+			str[len] = '\0';
+			return;
+		}
+	}
+}
+
+void semanage_keep_until_space(char *data)
+{
+	if (!data)
+		return;
+	while (*data && (!isspace(*data)))
+		++data;
+	*data = '\0';
+	return;
+}
+
+char *semanage_sed(char *src, char *val, char *replacement)
+{
+	char *dest;
+	char *temp;
+	int srclen;
+	int vallen;
+	int replen;
+	int maxdest;
+	int dindex = 0;
+	int sindex = 0;
+	int min_increment;
+
+	if (!src || !val || !replacement)
+		return NULL;
+
+	srclen = strlen(src);
+	vallen = strlen(val);
+	replen = strlen(replacement);
+
+	maxdest = 2 * srclen;
+	dest = malloc(maxdest);
+	if (!dest)
+		return NULL;
+
+	for (sindex = 0; sindex < srclen;) {
+		/* if the replacement length >= space left at the end of the string
+		 * allocate new space, double the string and add the minimum increment
+		 * plus a byte for null termination (for good measure)
+		 */
+		min_increment = (dindex + replen + 1) - maxdest;
+		if (min_increment >= 0) {
+			maxdest = maxdest * 2 + min_increment;
+			temp = realloc(dest, maxdest);
+			if (!temp) {
+				free(dest);
+				return NULL;
+			}
+			dest = temp;
+		}
+		if ((sindex + vallen <= srclen)
+		    && semanage_prefix_of((src + sindex), val)) {
+			strcpy((dest + dindex), replacement);
+			dindex += replen;
+			sindex += vallen;
+		} else {
+			dest[dindex++] = src[sindex++];
+		}
+	}
+	dest[dindex] = '\0';
+	return dest;
+}
+
+list_t *semanage_slurp_file_filter(FILE * file, int (*pred) (char *))
+{
+	list_t head;
+	list_t *current = &head;
+	char *line = NULL;
+
+	int count = 0;
+
+	head.next = NULL;	/* initialize head, we aren't going to use the data */
+	while ((line = semanage_fgetline(file)) != NULL) {
+		if (count++ == 90)
+			exit(-1);
+		if (pred(line)) {
+			current = list_addafter_controlmem(current, line);
+			if (!current)
+				break;	// if there was an error break out of the loop
+		} else {
+			free(line);
+		}
+	}
+
+	return head.next;
+}
Index: ghdc/libsemanage/src/utilities.h
===================================================================
--- /dev/null
+++ ghdc/libsemanage/src/utilities.h
@@ -0,0 +1,157 @@
+/* Author: Mark Goldman   <mgoldman@tresys.com>
+ *
+ * Copyright (C) 2007 Tresys Technology, LLC
+ *
+ *  This library is free software; you can redistribute it and/or
+ *  modify it under the terms of the GNU Lesser General Public
+ *  License as published by the Free Software Foundation; either
+ *  version 2.1 of the License, or (at your option) any later version.
+ *
+ *  This library is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ *  Lesser General Public License for more details.
+ *
+ *  You should have received a copy of the GNU Lesser General Public
+ *  License along with this library; if not, write to the Free Software
+ *  Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
+ */
+
+/* This file contains helper functions that are loosely based off of what is
+ * available from the python script genhomedircon.  Also this file contains
+ * c implementations of a couple of python functions so that genhomedircon will
+ * look/act like the python script.
+ */
+#ifndef SELINUX_UTILITIES
+#define SELINUX_UTILITIES
+
+#include <sys/types.h>
+#include <regex.h>
+
+typedef struct list {
+	char *data;
+	struct list *next;
+} list_t;
+
+typedef struct relist {
+	regex_t *data;
+	struct relist *next;
+} relist_t;
+
+/**
+ * @param file  the path to the file to look for a variable in
+ * @param var   the variable that you want the value of
+ * @param delim the value that separates the part you care about from the part
+ *	       that you don't.
+ * @return for the first instance of var in the file, returns everything after
+ *	   delim.
+ *	   returns "" if not found IE if(*(semanage_findval(f,v,d)) == '\0'){
+ *					  printf("%s not found in file", v);
+ *				       }
+ *
+ *	   NULL for error (out of memory, etc)
+ */
+char *semanage_findval(char *file, char *var, char *delim);
+
+/**
+ * @param str   string to test
+ * @param	 val   prefix
+ * @return  1 if val is the prefix of str
+ *	    0 if val is not the prefix of str
+ *
+ * note: if str == NULL, returns false
+ *	 if val == NULL, returns true --nothing can always be the prefix of
+ *				        something
+ *	 if (*val) == "" returns true same as above.
+ */
+int semanage_prefix_of(char *str, char *val);
+
+/**
+ * @param str   the string to semanage_split
+ * @return     ptr to the first non-space (isspace()) charachter in the
+ *	       string after the first run of charachters that aren't whitespace
+ */
+char *semanage_split_on_space(char *str);
+
+/**
+ * @param	 str   the string to semanage_split
+ * @param	 delim the string delimiter.  NOT a set of charachters that can be
+ *	       a delimiter.
+ *	       if *delim == '\0' behaves as semanage_splitOnSpace()
+ * @return   a ptr to the first charachter past the delimiter.
+ *	    if delim doesn't appear in the string, returns a ptr to the
+ *	    trailing null in the string
+ */
+char *semanage_split(char *str, char *delim);
+
+/**
+ * @param f     the file to get the line from
+ * @param	 delim end of line marker
+ * @return  malloc'd buffer that holds the line.
+ *	    MUST BE FREE'd after function is done with the memory.
+ *	    returns NULL on error (lack of memory, etc)
+ *
+ * NOTE: There is a GNU extention that does this, re-implementing for
+ *	 portability.
+ */
+char *semanage_fgetline(FILE * f);
+
+/* linked list string functions
+ * Functions allocate memory.  Must be free'd with
+ * either semanage_list_pop until list == NULL or semanage_list_destroy()
+ */
+int semanage_list_push(list_t ** list, char *data);
+char *semanage_list_pop(list_t ** list);
+void semanage_list_destroy(list_t ** list);
+list_t *semanage_list_find(list_t * l, char *data);
+int semanage_list_sort(list_t ** l);
+/* function to compare 2 list_t nodes,
+ * returns strcmp(x->data, y->data)
+ * used internally by semanage_list_sort()
+ */
+int semanage_cmp_plist_t(const list_t ** x, const list_t ** y);
+/**
+ * @param      data a target string
+ * @param      what  a charachter
+ * @returns    the number of times the char appears in the string
+ */
+int semanage_str_count(char *data, char what);
+/**
+ * @param      - a string
+ * @param            the charachter to trim to
+ * @return   - mangles the string, converting the first
+ *             occurrance of the charachter to a '\0' from
+ *             the end of the string.
+ */
+void semanage_rtrim(char *str, char trim_to);
+
+/**
+ * @param data    some string
+ * @return  modifies the string such that the first whitespace char becomes
+ *	    '\0', ending the string.
+ */
+void semanage_keep_until_space(char *data);
+
+/**
+ * @param   src	     -  initial string
+ * @param   string   -	substring that you want to replace
+ * @param   replacement	-  what to replace string with
+ * @return  a malloc'd sting that needs to be free'd
+ *	    on error (out of memory) returns NULL
+ *
+ * NOTE:    while named semanage_sed, this function only supports
+ *	    text literal replacements.
+ */
+char *semanage_sed(char *src, char *string, char *replacement);
+
+/**
+ * @param    file    - an open FILE to read from
+ * @param    pred    - a function taking a string that
+ *                    returns 1 if the string should be
+ *                    kept and 0 otherwise
+ * @return  a list of lines from the file (empty lines become
+ *          empty strings) in the file order where pred(line)
+ *          returns > 0
+ */
+list_t *semanage_slurp_file_filter(FILE * file, int (*pred) (char *));
+#endif
Index: ghdc/libselinux/src/file_path_suffixes.h
===================================================================
--- ghdc.orig/libselinux/src/file_path_suffixes.h
+++ ghdc/libselinux/src/file_path_suffixes.h
@@ -16,5 +16,5 @@ S_(BINPOLICY, "/policy/policy")
     S_(SEUSERS, "/seusers")
     S_(TRANSLATIONS, "/setrans.conf")
     S_(NETFILTER_CONTEXTS, "/contexts/netfilter_contexts")
-    S_(FILE_CONTEXTS_HOMEDIR, "/contexts/files/file_contexts.homedir")
+    S_(FILE_CONTEXTS_HOMEDIR, "/contexts/files/file_contexts.homedirs")
     S_(FILE_CONTEXTS_LOCAL, "/contexts/files/file_contexts.local")

-- 

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [patch 1/3] libsemanage: genhomedircon replacement

[Karl MacMillan]

On Mon, 2007-05-21 at 05:54 -0400, jbrindle@tresys.com wrote:
> plain text document attachment (genhomedircon-replacement-initial)
> Remove python script genhomedircon from libsemanage and replace
> with C functionality.
> 
> Index: ghdc/libsemanage/src/genhomedircon.c
> ===================================================================
> --- /dev/null
> +++ ghdc/libsemanage/src/genhomedircon.c
> @@ -0,0 +1,590 @@
> +/* Author: Mark Goldman   <mgoldman@tresys.com>
> + *
> + * Copyright (C) 2007 Tresys Technology, LLC
> + *
> + *  This library is free software; you can redistribute it and/or modify
> + *  it under the terms of the GNU Lesser General Public License as
> + *  published by the Free Software Foundation; either version 2.1 of the
> + *  License, or (at your option) any later version.
> + *
> + *  This library is distributed in the hope that it will be useful, but
> + *  WITHOUT ANY WARRANTY; without even the implied warranty of
> + *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + *  Lesser General Public License for more details.
> + *
> + *  You should have received a copy of the GNU Lesser General Public
> + *  License along with this library; if not, write to the Free Software
> + *  Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
> + *  02110-1301  USA
> + */
> +#include <assert.h>
> +#include <limits.h>
> +#include <stdio.h>
> +#include <stdlib.h>
> +#include <string.h>
> +#include <sys/types.h>
> +#include <sys/stat.h>
> +#include <fcntl.h>
> +#include <pwd.h>
> +

I prefer system includes to be last - it helps prevent missing includes
in public headers. (but that's just my opinion - we don't enforce the
convention)

> +#include <semanage/handle.h>
> +#include <semanage/seusers_policy.h>
> +#include <semanage/users_policy.h>
> +#include <semanage/user_record.h>
> +#include "semanage_store.h"
> +#include "seuser_internal.h"
> +#include "debug.h"
> +
> +#include "utilities.h"
> +#include "genhomedircon.h"
> +
> +static int fwriteoutput(state_t * s, FILE * out);
> +

Please don't define static functions - simply order the .c file
correctly.


> +/* should default to usepasswd */

This comment seems to be meaningless.

> +int semanage_genhomedircon(semanage_handle_t * sh, int usepasswd)
> +{
> +	state_t s;
> +
> +	char outfile[PATH_MAX];
> +	char hdt[PATH_MAX];
> +	char fcf[PATH_MAX];
> +
> +	FILE *out = NULL;
> +	int retval = 0;
> +
> +	assert(sh);
> +
> +	s.homedir_template_path = hdt;
> +	snprintf(s.homedir_template_path, PATH_MAX - 1, "%s",
> +		 semanage_path(SEMANAGE_TMP, SEMANAGE_HOMEDIR_TMPL));
> +
> +	snprintf(outfile, PATH_MAX - 1, "%s",
> +		 semanage_path(SEMANAGE_TMP, SEMANAGE_FC_HOMEDIRS));
> +

strdup?

> +	s.fcfilepath = fcf;
> +
> +	snprintf(s.fcfilepath, PATH_MAX - 1, "%s",
> +		 semanage_path(SEMANAGE_TMP, SEMANAGE_FC_HOMEDIRS));
> +

ditto

> +	s.usepasswd = usepasswd;
> +	s.h_semanage = sh;
> +
> +	if (!(out = fopen(s.fcfilepath, "w"))) {
> +		/* couldn't open output file */
> +		ERR(sh, "Could not open the file_context file for writing");
> +		retval = STATUS_ERR;
> +		goto out;

This should just return, otherwise you are trying to close a file that
isn't open.

> +	}
> +
> +	fwriteoutput(&s, out);
> +

You should check the return value.

> +      out:

If you remove the previous goto this target can go.

> +	fclose(out);
> +	return retval;
> +}
> +
> +static list_t *default_shell_list(void)
> +{

What is this function for? Why not error out when /etc/shells is not
available?

> +	list_t *list = NULL;

Why are you adding another list type when we just merged one into
libsepol? If you want this merged into trunk before policyrep let's move
the list type over early.

> +	semanage_list_push(&list, "/bin/csh");
> +	semanage_list_push(&list, "/bin/tcsh");
> +	semanage_list_push(&list, "/bin/ksh");
> +	semanage_list_push(&list, "/bin/bsh");
> +	semanage_list_push(&list, "/bin/ash");
> +	semanage_list_push(&list, "/usr/bin/ksh");
> +	semanage_list_push(&list, "/usr/bin/pdksh");
> +	semanage_list_push(&list, "/bin/zsh");
> +	semanage_list_push(&list, "/bin/sh");
> +	semanage_list_push(&list, "/bin/bash");
> +	return list;
> +}
> +
> +static list_t *get_shell_list(void)
> +{
> +	FILE *shells;
> +	char *temp = NULL;
> +	list_t *list = NULL;
> +
> +	shells = fopen("/etc/shells", "r");
> +	if (!shells)
> +		return default_shell_list();

See above - when is this error possible and why not make it fatal.

> +	while ((temp = semanage_fgetline(shells))) {

You should use getline - we already depend on GNU extensions.

> +		if (!strcmp(temp, "/sbin/nologin")) {
> +			free(temp);
> +			continue;
> +		}
> +		semanage_list_push(&list, temp);
> +		free(temp);
> +	}
> +	return list;
> +}
> +
> +static list_t *get_home_dirs(state_t * s)
> +{
> +	list_t *l = NULL;
> +	list_t *shells = NULL;
> +	char *path;
> +	size_t minuid = 2000000;	/* sentinal value, UIDs can't be
> +					 * above ~64k */
> +	size_t temp;
> +	struct passwd *pwbuf;
> +	struct stat buf;
> +
> +	path = semanage_findval("/etc/default/useradd", "HOME", "=");
> +	if (path && *path) {
> +		semanage_list_push(&l, path);
> +	}
> +	free(path);
> +
> +	path = semanage_findval("/etc/libuser.conf", "LU_HOMEDIRECTORY", "=");
> +	if (path && *path) {
> +		semanage_list_push(&l, path);
> +	}
> +	free(path);
> +
> +	if (!l)
> +		semanage_list_push(&l, strdup("/home"));
> +
> +	if (!stat("/export/home", &buf)) {
> +		if (buf.st_mode | S_IFDIR)
> +			semanage_list_push(&l, strdup("/export/home"));
> +	}
> +
> +	if (!(s->usepasswd))
> +		return l;
> +
> +	path = semanage_findval("/etc/login.defs", "UID_MIN", NULL);
> +	if (path && *path) {
> +		temp = atoi(path);
> +		if (temp < minuid)
> +			minuid = temp;
> +	}
> +	free(path);
> +
> +	path = semanage_findval("/etc/libuser.conf", "LU_UIDNUMBER", "=");
> +	if (path && *path) {
> +		temp = atoi(path);
> +		if (temp < minuid)
> +			minuid = temp;
> +	}
> +	free(path);
> +
> +	if (minuid == 2000000)
> +		minuid = 500;

Please use a boolean value to indicate whether minuid is set.

> +
> +	shells = get_shell_list();
> +

Error checking.

> +	setpwent();
> +	while ((pwbuf = getpwent())) {

You need to check errno to see if there was an error.

It is not clear from the python docs, but getpwent will definitely pull
user entries from LDAP, NIS, etc. Is that what we want or should we
limit to /etc/passwd only?

> +		if (pwbuf->pw_uid < minuid)
> +			continue;
> +		if (!semanage_list_find(shells, pwbuf->pw_shell))
> +			continue;
> +		if (strcmp(pwbuf->pw_dir, "/") == 0)
> +			continue;
> +		if (semanage_str_count(pwbuf->pw_dir, '/') <= 1)
> +			continue;
> +		path = strdup(pwbuf->pw_dir);
> +		semanage_rtrim(path, '/');
> +		if (!semanage_list_find(l, path)) {
> +			semanage_list_push(&l, path);	
> +		}
> +		free(path);
> +	}
> +
> +	/* clean up: I'm returning l so I don't need to do anything with it.
> +	 *           I free the memory pointed to by path as soon as I'm done.
> +	 *           That leaves the shells list which I destoy here.
> +	 */
> +	endpwent();
> +	semanage_list_destroy(&shells);
> +
> +	semanage_list_sort(&l);
> +	return l;
> +}
> +
> +/**
> + * @param	s	state structure, stores various paths etc. Must never be NULL
> + * @param	out	the FILE to put all the output in.
> + * @return	0 on success
> + */
> +static int fwriteheader(state_t * s, FILE * out)
> +{

Needs a better function name.

> +
> +	fprintf(out,
> +		"#\n#\n# User-specific file contexts, generated via libsemanage\n");
> +	fprintf(out,
> +		"# use semanage command to manage system users to change the"
> +		" file_context\n#\n#\n");
> +	return 0;
> +}
> +
> +/* Predicates for use with semanage_slurp_file_filter() the homedir_template file
> + * currently contains lines that serve as the template for a user's
> + * homedir.
> + *
> + * It also contains lines that are the template for the parent of a
> + * user's home directory.
> + *
> + * Currently, the only lines that apply to the the root of a user's home
> + * directory are all prefixed with the string "HOME_ROOT".  All other
> + * lines apply to a user's home directory.  If this changes the
> + * following predicates need to change to reflect that.
> + */
> +static int HOME_ROOT_PRED(char *string)
> +{
> +	return semanage_prefix_of(string, "HOME_ROOT");
> +}
> +
> +static int HOME_DIR_PRED(char *string)
> +{
> +	return semanage_prefix_of(string, "HOME_DIR");
> +}
> +
> +static int USER_CONTEXT_PRED(char *string)
> +{
> +	return (int)(strstr(string, "USER") != NULL);
> +}
> +
> +/* make_home_dir_tempate
> + * make_home_root_template
> + * @param	s	  the state holding the paths to various files
> + * @return   a list of lines from the template file with inappropriate
> + *	    lines filtered out.
> + */
> +static list_t *make_home_dir_template(state_t * s)
> +{
> +	FILE *template_file = NULL;
> +	list_t *template_data = NULL;
> +
> +	template_file = fopen(s->homedir_template_path, "r");
> +	if (!template_file)
> +		return NULL;
> +	template_data = semanage_slurp_file_filter(template_file, &HOME_DIR_PRED);
> +	fclose(template_file);
> +	return template_data;
> +}
> +
> +static list_t *make_home_root_template(state_t * s)
> +{
> +	FILE *template_file = NULL;
> +	list_t *template_data = NULL;
> +
> +	template_file = fopen(s->homedir_template_path, "r");
> +	if (!template_file)
> +		return NULL;
> +	template_data = semanage_slurp_file_filter(template_file, &HOME_ROOT_PRED);
> +	fclose(template_file);
> +	return template_data;
> +}
> +
> +static list_t *make_user_context_template(state_t * s)
> +{
> +	FILE *template_file = NULL;
> +	list_t *template_data = NULL;
> +
> +	template_file = fopen(s->homedir_template_path, "r");
> +	if (!template_file)
> +		return NULL;
> +	template_data = semanage_slurp_file_filter(template_file, &USER_CONTEXT_PRED);
> +	fclose(template_file);
> +	return template_data;
> +}
> +
> +static int write_home_dir_context(FILE * out, list_t * tpl, char *user,
> +				  char *seuser, char *home, char *prefix)
> +{
> +	char *temp;
> +	char *line;
> +
> +	fprintf(out, "\n\n#\n# Home Context for user %s\n#\n\n", user);
> +	for (; tpl; tpl = tpl->next) {
> +		temp = semanage_sed(tpl->data, "HOME_DIR", home);

Wow - I understand that this string handling in C is painful, but is
this really the best alternative? Perhaps parsing the input to make the
substitution easier would be better? Perhaps we should look for some
library code to do this?

> +		if (!temp)
> +			return -1;
> +		line = temp;
> +		temp = semanage_sed(line, "ROLE", prefix);
> +		free(line);
> +		if (!temp)
> +			return -1;
> +		line = temp;
> +		temp = semanage_sed(line, "system_u", seuser);
> +		free(line);
> +		if (!temp)
> +			return -1;
> +		line = temp;
> +		fputs(line, out);
> +		fputs("\n", out);
> +		free(line);
> +	}
> +	return 0;
> +}
> +
> +static int write_home_root_context(FILE * out, list_t * tpl, char *homedir)
> +{
> +	char *temp;
> +
> +	for (; tpl; tpl = tpl->next) {
> +		temp = semanage_sed(tpl->data, "HOME_ROOT", homedir);
> +		if (!temp)
> +			return -1;
> +		fputs(temp, out);
> +		fputs("\n", out);
> +		free(temp);
> +	}
> +	return 0;
> +}
> +
> +static int write_user_context(FILE * out, list_t * tpl, char *user,
> +			      char *seuser, char *prefix)
> +{
> +	char *temp;
> +	char *line;
> +
> +	for (; tpl; tpl = tpl->next) {
> +		temp = semanage_sed(tpl->data, "USER", user);
> +		if (!temp)
> +			return -1;
> +		line = temp;
> +		temp = semanage_sed(line, "ROLE", prefix);
> +		free(line);
> +		if (!temp)
> +			return -1;
> +		line = temp;
> +		temp = semanage_sed(line, "system_u", seuser);
> +		free(line);
> +		if (!temp)
> +			return -1;
> +		line = temp;
> +		fputs(line, out);
> +		fputs("\n", out);
> +		free(line);
> +	}
> +	return 0;
> +}
> +
> +static int user_sort_func(semanage_user_t ** arg1, semanage_user_t ** arg2)
> +{
> +	return strcmp(semanage_user_get_name(*arg1),
> +		      semanage_user_get_name(*arg2));
> +}
> +
> +static int name_user_cmp(char *key, semanage_user_t ** val)
> +{
> +	int ret = strcmp(key, semanage_user_get_name(*val));
> +	return ret;
> +}
> +
> +static int push_user_entry(user_entry_t ** list, const char *n, const char *sen,
> +			   const char *pre, const char *h)
> +{
> +	user_entry_t *temp = NULL;
> +	char *name = NULL;
> +	char *sename = NULL;
> +	char *prefix = NULL;
> +	char *home = NULL;
> +
> +	temp = malloc(sizeof(user_entry_t));
> +	if (!temp)
> +		goto cleanup;
> +	name = strdup(n);
> +	if (!name)
> +		goto cleanup;
> +	sename = strdup(sen);
> +	if (!sename)
> +		goto cleanup;
> +	prefix = strdup(pre);
> +	if (!prefix)
> +		goto cleanup;
> +	home = strdup(h);
> +	if (!home)
> +		goto cleanup;
> +
> +	temp->name = name;
> +	temp->sename = sename;
> +	temp->prefix = prefix;
> +	temp->home = home;
> +	temp->next = (*list);
> +	(*list) = temp;
> +
> +	return 0;
> +
> +      cleanup:
> +	free(name);
> +	free(sename);
> +	free(prefix);
> +	free(home);
> +	free(temp);
> +	return -1;
> +}
> +
> +static void pop_user_entry(user_entry_t ** list)
> +{
> +	user_entry_t *temp;
> +
> +	if (!list || !(*list))
> +		return;
> +	temp = *list;
> +	*list = temp->next;
> +	free(temp->name);
> +	free(temp->sename);
> +	free(temp->prefix);
> +	free(temp->home);
> +	free(temp);
> +	return;
> +}
> +
> +static user_entry_t *get_users(state_t * s)
> +{
> +	user_entry_t *head = NULL;
> +
> +	semanage_seuser_t **seuser_list = NULL;
> +	unsigned int nseusers = 0;
> +
> +	semanage_user_t **user_list = NULL;
> +	unsigned int nusers = 0;
> +
> +	semanage_user_t **u = NULL;
> +	const char *name = NULL;
> +	const char *seuname = NULL;
> +	const char *prefix = NULL;
> +
> +	struct passwd *pwent = NULL;
> +
> +	unsigned int i;
> +	int retval;
> +
> +	if ((retval =
> +	     semanage_seuser_list(s->h_semanage, &seuser_list, &nseusers) < 0)
> +	    || (nseusers < 1)) {
> +		/* if there are no users, this function can't do any other work */
> +		return NULL;
> +	}
> +
> +	if (semanage_user_list(s->h_semanage, &user_list, &nusers) < 0) {
> +		nusers = 0;
> +	}
> +
> +	qsort(user_list, nusers, sizeof(semanage_user_t *),
> +	      (int (*)(const void *, const void *))&user_sort_func);
> +
> +	for (i = 0; i < nseusers; i++) {
> +		name = semanage_seuser_get_name(seuser_list[i]);
> +		seuname = semanage_seuser_get_sename(seuser_list[i]);
> +
> +		if (strcmp(seuname, "user_u") == 0)
> +			continue;
> +		if (strcmp(seuname, "__default__") == 0)
> +			continue;
> +		if (strcmp(seuname, "system_u") == 0)
> +			continue;
> +
> +		/* find the user structure givent the name */
> +		u = bsearch(name, user_list, nusers, sizeof(semanage_user_t *),
> +			    (int (*)(const void *, const void *))
> +			    &name_user_cmp);
> +		if (u) {
> +			prefix = semanage_user_get_prefix(*u);
> +		} else {
> +			prefix = name;
> +		}
> +
> +		pwent = getpwnam(name);
> +		if (!pwent) {
> +			/* user not in passwd file, genhomedircon
> +			 * printed a message here */
> +			continue;
> +		}
> +
> +		if (strcmp(pwent->pw_dir, "/") == 0) {
> +			/* don't relabel / genhomdircon checked to see if root
> +			 * was the user and if so, set his home directory to
> +			 * /root */
> +			continue;
> +		}
> +
> +		push_user_entry(&head, name, seuname, prefix, pwent->pw_dir);
> +	}
> +	for (i = 0; i < nseusers; i++) {
> +		semanage_seuser_free(seuser_list[i]);
> +	}
> +	free(seuser_list);
> +
> +	for (i = 0; i < nusers; i++) {
> +		semanage_user_free(user_list[i]);
> +	}
> +	free(user_list);
> +	return head;
> +}
> +
> +static int write_gen_home_dir_context(FILE * out, state_t * s,
> +				      list_t * user_context_tpl,
> +				      list_t * homedir_context_tpl)
> +{
> +	user_entry_t *users;
> +
> +	for (users = get_users(s); users; pop_user_entry(&users)) {
> +		write_home_dir_context(out, homedir_context_tpl,
> +				       users->name,
> +				       users->sename, users->home,
> +				       users->prefix);
> +		write_user_context(out, user_context_tpl, users->name,
> +				   users->sename, users->prefix);
> +	}
> +	return 0;
> +}
> +
> +/**
> + * @param	s	state structure, stores various paths etc. Must never be NULL
> + * @param	out	the FILE to put all the output in.
> + * @return	0 on success
> + */
> +static int fwriteoutput(state_t * s, FILE * out)
> +{

This function name should be more descriptive.

> +	list_t *homedirs = NULL;
> +	list_t *h = NULL;
> +	list_t *user_context_tpl = NULL;
> +	list_t *homedir_context_tpl = NULL;
> +	list_t *homeroot_context_tpl = NULL;
> +
> +	char *temp;
> +	int s1len;
> +
> +	homedirs = get_home_dirs(s);
> +	if (!homedirs) {
> +		WARN(s->h_semanage,
> +		     "no home directories were available, exiting without writing");
> +		return -1;	/* No homedirs so no output */
> +	}
> +
> +	fwriteheader(s, out);
> +
> +	homedir_context_tpl = make_home_dir_template(s);
> +	homeroot_context_tpl = make_home_root_template(s);
> +	user_context_tpl = make_user_context_template(s);
> +
> +	for (h = homedirs; h; h = h->next) {
> +		s1len = strlen(h->data);
> +		temp = malloc(s1len + sizeof("/[^/]*"));
> +		strcpy(temp, h->data);
> +		strcpy(temp + s1len, "/[^/]*");

strdup

> +
> +		write_home_dir_context(out,
> +				       homedir_context_tpl, "user_u", "user_u",
> +				       temp, "user");
> +		write_home_root_context(out, homeroot_context_tpl, h->data);
> +
> +		free(temp);
> +	}
> +	write_user_context(out, user_context_tpl, ".*", "user_u", "user");
> +	write_gen_home_dir_context(out, s, user_context_tpl,
> +				   homedir_context_tpl);
> +
> +	/* Cleanup */
> +	semanage_list_destroy(&homedirs);
> +	semanage_list_destroy(&user_context_tpl);
> +	semanage_list_destroy(&homedir_context_tpl);
> +	semanage_list_destroy(&homeroot_context_tpl);
> +
> +	return 0;
> +}
> Index: ghdc/libsemanage/src/genhomedircon.h
> ===================================================================
> --- /dev/null
> +++ ghdc/libsemanage/src/genhomedircon.h
> @@ -0,0 +1,42 @@
> +/* Author: Mark Goldman   <mgoldman@tresys.com>
> + *
> + * Copyright (C) 2007 Tresys Technology, LLC
> + *
> + *  This library is free software; you can redistribute it and/or
> + *  modify it under the terms of the GNU Lesser General Public
> + *  License as published by the Free Software Foundation; either
> + *  version 2.1 of the License, or (at your option) any later version.
> + *
> + *  This library is distributed in the hope that it will be useful,
> + *  but WITHOUT ANY WARRANTY; without even the implied warranty of
> + *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + *  Lesser General Public License for more details.
> + *
> + *  You should have received a copy of the GNU Lesser General Public
> + *  License along with this library; if not, write to the Free Software
> + *  Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
> + */
> +
> +#ifndef selinux_genhomedircon
> +#define selinux_genhomedircon
> +

These header guards don't match the rest of the library - should be
_SEMANAGE_GENHOMEDIRCON_H_.

> +#include "utilities.h"
> +
> +typedef struct {
> +	char *fcfilepath;
> +	int usepasswd;
> +	char *homedir_template_path;
> +	semanage_handle_t *h_semanage;
> +} state_t;
> +

This needs to be namespaced and have a better name. Also - does it need
to be exported?

> +typedef struct user_entry {
> +	char *name;
> +	char *sename;
> +	char *prefix;
> +	char *home;
> +	struct user_entry *next;
> +} user_entry_t;
> +

ditto

> +int semanage_genhomedircon(semanage_handle_t * sh, int usepasswd);
> +
> +#endif
> Index: ghdc/libsemanage/src/semanage_store.c
> ===================================================================
> --- ghdc.orig/libsemanage/src/semanage_store.c
> +++ ghdc/libsemanage/src/semanage_store.c
> @@ -34,6 +34,7 @@ typedef struct dbase_policydb dbase_t;
>  #include "semanage_store.h"
>  #include "database_policydb.h"
>  #include "handle.h"
> +#include "genhomedircon.h"
>  
>  #include <selinux/selinux.h>
>  #include <sepol/policydb.h>
> @@ -110,6 +111,7 @@ static const char *semanage_sandbox_path
>  	"/seusers.final",
>  	"/users_extra",
>  	"/netfilter_contexts",
> +	"/file_contexts.homedirs",
>  };
>  
>  /* A node used in a linked list of file contexts; used for sorting.
> @@ -1008,14 +1010,15 @@ static int semanage_install_active(seman
>  	const char *active_fc = semanage_path(SEMANAGE_ACTIVE, SEMANAGE_FC);
>  	const char *active_fc_loc =
>  	    semanage_path(SEMANAGE_ACTIVE, SEMANAGE_FC_LOCAL);
> -	const char *active_hd =
> -	    semanage_path(SEMANAGE_ACTIVE, SEMANAGE_HOMEDIR_TMPL);
>  	const char *active_seusers =
>  	    semanage_path(SEMANAGE_ACTIVE, SEMANAGE_SEUSERS);
>  	const char *active_nc = semanage_path(SEMANAGE_ACTIVE, SEMANAGE_NC);
> +	const char *active_fc_hd =
> +	    semanage_path(SEMANAGE_ACTIVE, SEMANAGE_FC_HOMEDIRS);
>  
>  	const char *running_fc = selinux_file_context_path();
>  	const char *running_fc_loc = selinux_file_context_local_path();
> +	const char *running_fc_hd = selinux_file_context_homedir_path();
>  	const char *running_hd = selinux_homedir_context_path();
>  	const char *running_policy = selinux_binary_policy_path();
>  	const char *running_seusers = selinux_usersconf_path();
> @@ -1027,14 +1030,15 @@ static int semanage_install_active(seman
>  	 * POLICYTYPE and should probably be done in the future. */
>  	char store_fc[PATH_MAX];
>  	char store_fc_loc[PATH_MAX];
> -	char store_hd[PATH_MAX];
>  	char store_pol[PATH_MAX];
>  	char store_seusers[PATH_MAX];
>  	char store_nc[PATH_MAX];
> +	char store_fc_hd[PATH_MAX];
>  
>  	len = strlen(really_active_store);
>  	running_fc += len;
>  	running_fc_loc += len;
> +	running_fc_hd += len;
>  	running_hd += len;
>  	running_policy += len;
>  	running_seusers += len;
> @@ -1055,9 +1059,10 @@ static int semanage_install_active(seman
>  		goto cleanup;
>  	}
>  
> -	snprintf(store_hd, PATH_MAX, "%s%s", storepath, running_hd);
> -	if (semanage_copy_file(active_hd, store_hd, sh->conf->file_mode) == -1) {
> -		ERR(sh, "Could not copy %s to %s.", active_hd, store_hd);
> +	snprintf(store_fc_hd, PATH_MAX, "%s%s", storepath, running_fc_hd);
> +	if (semanage_copy_file(active_fc_hd, store_fc_hd, sh->conf->file_mode)
> +	    == -1) {
> +		ERR(sh, "Could not copy %s to %s.", active_fc_hd, store_fc_hd);
>  		goto cleanup;
>  	}
>  
> @@ -1197,6 +1202,10 @@ static int semanage_commit_sandbox(seman
>  		retval = -1;
>  		goto cleanup;
>  	}
> +
> +	/* clean up some files from the sandbox before install */
> +	/* remove homedir_template from sandbox */
> +
>  	if (rename(sandbox, active) == -1) {
>  		ERR(sh, "Error while renaming %s to %s.", sandbox, active);
>  		/* note that if an error occurs during the next
> @@ -1227,7 +1236,8 @@ static int semanage_commit_sandbox(seman
>  	if (!sh->conf->save_previous) {
>  		retval = semanage_remove_directory(backup);
>  		if (retval < 0) {
> -			ERR(sh, "Could not delete previous directory %s.", backup);
> +			ERR(sh, "Could not delete previous directory %s.",
> +			    backup);
>  			goto cleanup;
>  		}
>  	}
> @@ -1257,15 +1267,15 @@ int semanage_install_sandbox(semanage_ha
>  		goto cleanup;
>  	}
>  
> -	if ((commit_num = semanage_commit_sandbox(sh)) < 0) {
> -		retval = commit_num;
> +	if ((retval =
> +	     semanage_genhomedircon(sh, 1)) != 0) {
> +		ERR(sh, "semanage_genhomedircon returned error code %d.",
> +		    retval);
>  		goto cleanup;
>  	}
>  
> -	if ((retval =
> -	     semanage_exec_prog(sh, sh->conf->genhomedircon,
> -				sh->conf->store_path, "")) != 0) {
> -		ERR(sh, "genhomedircon returned error code %d.", retval);
> +	if ((commit_num = semanage_commit_sandbox(sh)) < 0) {
> +		retval = commit_num;
>  		goto cleanup;
>  	}
>  
> Index: ghdc/libsemanage/src/utilities.c
> ===================================================================
> --- /dev/null
> +++ ghdc/libsemanage/src/utilities.c
> @@ -0,0 +1,359 @@
> +/* Author: Mark Goldman   <mgoldman@tresys.com>
> + *
> + * Copyright (C) 2007 Tresys Technology, LLC
> + *
> + *  This library is free software; you can redistribute it and/or
> + *  modify it under the terms of the GNU Lesser General Public
> + *  License as published by the Free Software Foundation; either
> + *  version 2.1 of the License, or (at your option) any later version.
> + *
> + *  This library is distributed in the hope that it will be useful,
> + *  but WITHOUT ANY WARRANTY; without even the implied warranty of
> + *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + *  Lesser General Public License for more details.
> + *
> + *  You should have received a copy of the GNU Lesser General Public
> + *  License along with this library; if not, write to the Free Software
> + *  Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
> + */
> +
> +#include <stdio.h>
> +#include <stdlib.h>
> +#include <ctype.h>
> +#include <string.h>
> +#include <sys/types.h>
> +#include <regex.h>
> +
> +#include "utilities.h"
> +
> +char *semanage_findval(char *file, char *var, char *delim)
> +{
> +	FILE *fd;
> +
> +	char *buff;
> +	char *temp = NULL;
> +
> +	if (!file || !var || !delim)
> +		return NULL;

assert?

> +
> +	if ((fd = fopen(file, "r")) == NULL)
> +		return NULL;
> +
> +	while (!feof(fd)) {
> +		if (!(buff = semanage_fgetline(fd))){
> +			goto err;
> +		}
> +		if (semanage_prefix_of(buff, var)) {
> +			/* Found it */
> +			temp = semanage_split(buff, delim);
> +			/* if semanage_split succedes dup the token */
> +			if (temp != NULL)
> +				temp = strdup(temp);
> +			free(buff);	/* free the buffer */
> +			goto out;
> +		}
> +		free(buff);	/* free the buffer for next time through the loop */
> +	}
> +
> +err:
> +	temp = NULL;
> +out:
> +	fclose(fd);
> +	return temp;
> +
> +}
> +
> +int semanage_prefix_of(char *str, char *val)
> +{

We commonly use is to denote boolean return - i.e.
semanage_str_is_prefix(char *str, char *prefix).

> +	if (!str)
> +		return 0;
> +	if (!val)
> +		return 1;
> +
> +	while ((*str) && (*val) && (*str == *val)) {
> +		++str;
> +		++val;
> +	}
> +
> +	return !(*val);
> +}
> +
> +char *semanage_split_on_space(char *str)
> +{
> +	if (!str)
> +		return NULL;
> +
> +	while ((*str != '\0') && !(isspace(*str)))
> +		str++;
> +	while ((*str != '\0') && (isspace(*str)))
> +		str++;
> +
> +	return str;
> +}
> +
> +char *semanage_split(char *str, char *delim)
> +{
> +	char *temp = str;
> +
> +	if (!str)
> +		return NULL;
> +	if (!delim || (*delim == '\0'))
> +		return semanage_split_on_space(str);

Having NULL mean space seems odd.

> +
> +	strsep(&temp, delim);	/* temp gets updated to the char past delim */
> +
> +	return temp;
> +}
> +
> +char *semanage_fgetline(FILE * f)
> +{

Replace with getline.

Karl


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [patch 1/3] libsemanage: genhomedircon replacement

[Mark Goldman]

On Tue, 2007-05-22 at 17:08 -0400, Karl MacMillan wrote:
<snip>
> > +int semanage_genhomedircon(semanage_handle_t * sh, int usepasswd)
> > +{
> > +	state_t s;
> > +
> > +	char outfile[PATH_MAX];
> > +	char hdt[PATH_MAX];
> > +	char fcf[PATH_MAX];
> > +
> > +	FILE *out = NULL;
> > +	int retval = 0;
> > +
> > +	assert(sh);
> > +
> > +	s.homedir_template_path = hdt;
> > +	snprintf(s.homedir_template_path, PATH_MAX - 1, "%s",
> > +		 semanage_path(SEMANAGE_TMP, SEMANAGE_HOMEDIR_TMPL));
> > +
> > +	snprintf(outfile, PATH_MAX - 1, "%s",
> > +		 semanage_path(SEMANAGE_TMP, SEMANAGE_FC_HOMEDIRS));
> > +
> 
> strdup?
The paths are allocated on the stack.  Can't strdup them.  All things being
equal, I would prefer to keep them on the stack since that is three
fewer items I could possibly leak.

> > +static list_t *default_shell_list(void)
> > +{
> 
> What is this function for? Why not error out when /etc/shells is not
> available?
Well, the justification here as with several other places is
"genhomedircon didn't".

> > +	list_t *list = NULL;
> 
> Why are you adding another list type when we just merged one into
> libsepol? If you want this merged into trunk before policyrep let's move
> the list type over early.
I'm working off of trunk.  If it isn't in trunk it I can't use it.

<snip>
> > +	shells = fopen("/etc/shells", "r");
> > +	if (!shells)
> > +		return default_shell_list();
> 
> See above - when is this error possible and why not make it fatal.
Again, "it wasn't fatal in genhomedircon"

<snip>
> > +	setpwent();
> > +	while ((pwbuf = getpwent())) {
> 
> You need to check errno to see if there was an error.
> 
> It is not clear from the python docs, but getpwent will definitely pull
> user entries from LDAP, NIS, etc. Is that what we want or should we
> limit to /etc/passwd only?
>From what I've been able to gather, python's getpwall is a wrapper 
for getpwent. As for whether we want this behavior or not, I'm open 
to suggestions.

<snip>
> > +static int fwriteheader(state_t * s, FILE * out)
> > +{
> 
> Needs a better function name.
Suggestions?

<snip>
> > +static int write_home_dir_context(FILE * out, list_t * tpl, char *user,
> > +				  char *seuser, char *home, char *prefix)
> > +{
> > +	char *temp;
> > +	char *line;
> > +
> > +	fprintf(out, "\n\n#\n# Home Context for user %s\n#\n\n", user);
> > +	for (; tpl; tpl = tpl->next) {
> > +		temp = semanage_sed(tpl->data, "HOME_DIR", home);
> 
> Wow - I understand that this string handling in C is painful, but is
> this really the best alternative? Perhaps parsing the input to make the
> substitution easier would be better? Perhaps we should look for some
> library code to do this?
I am not really sure what the problem with this is.  We need to replace
arbitrary substrings.  I searched in the C libraries for something that
might do what I want.  I couldn't find anything, so I wrote a function
to do it.

As for parsing the input to make the substitution easier, I think it
would be a lot more work to write or use a full fledged parser.  What
we want in this situation is what I wrote in my opinion, although I am
open to suggestions.

<snip>
> > +static int fwriteoutput(state_t * s, FILE * out)
> > +{
> 
> This function name should be more descriptive.
Suggestions?

<snip>
> > +	for (h = homedirs; h; h = h->next) {
> > +		s1len = strlen(h->data);
> > +		temp = malloc(s1len + sizeof("/[^/]*"));
> > +		strcpy(temp, h->data);
> > +		strcpy(temp + s1len, "/[^/]*");
> 
> strdup
I needed extra space at the end of the string for the suffix, so I malloc'd
it all in one go.

<snip>
> > +char *semanage_findval(char *file, char *var, char *delim)
> > +{
> > +	FILE *fd;
> > +
> > +	char *buff;
> > +	char *temp = NULL;
> > +
> > +	if (!file || !var || !delim)
> > +		return NULL;
> 
> assert?
As with other things, genhomedircon would not have aborted on this
condition.  It returned "" on all exceptional paths.

<snip>
> > +char *semanage_split(char *str, char *delim)
> > +{
> > +	char *temp = str;
> > +
> > +	if (!str)
> > +		return NULL;
> > +	if (!delim || (*delim == '\0'))
> > +		return semanage_split_on_space(str);
> 
> Having NULL mean space seems odd.
This function was a python emulation function.  It behaves in the manner
that python's split would if you don't pass in a delimiter.

Consider all unmentioned comments Noted and fixed.

-mdg 


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [patch 1/3] libsemanage: genhomedircon replacement

[Karl MacMillan]

On Thu, 2007-05-24 at 10:04 -0400, Mark Goldman wrote:
> On Tue, 2007-05-22 at 17:08 -0400, Karl MacMillan wrote:
> <snip>
> > > +int semanage_genhomedircon(semanage_handle_t * sh, int usepasswd)
> > > +{
> > > +	state_t s;
> > > +
> > > +	char outfile[PATH_MAX];
> > > +	char hdt[PATH_MAX];
> > > +	char fcf[PATH_MAX];
> > > +
> > > +	FILE *out = NULL;
> > > +	int retval = 0;
> > > +
> > > +	assert(sh);
> > > +
> > > +	s.homedir_template_path = hdt;
> > > +	snprintf(s.homedir_template_path, PATH_MAX - 1, "%s",
> > > +		 semanage_path(SEMANAGE_TMP, SEMANAGE_HOMEDIR_TMPL));
> > > +
> > > +	snprintf(outfile, PATH_MAX - 1, "%s",
> > > +		 semanage_path(SEMANAGE_TMP, SEMANAGE_FC_HOMEDIRS));
> > > +
> > 
> > strdup?
> The paths are allocated on the stack.  Can't strdup them.  All things being
> equal, I would prefer to keep them on the stack since that is three
> fewer items I could possibly leak.
> 

I think malloc'd would be better because otherwise you have to do this
fun with PATH_MAX and snprintfs (which is hard to read) and end up with
a lot of data on the stack. Question - do you even need to copy these?
Why not just store a pointer to what is returned by semanage_path?

> > > +static list_t *default_shell_list(void)
> > > +{
> > 
> > What is this function for? Why not error out when /etc/shells is not
> > available?
> Well, the justification here as with several other places is
> "genhomedircon didn't".
> 

I think the behavior should be similar, but there is no reason that we
can't make changes to corner case behavior if we think it would be
better. So I don't think an _exact_ port is necessary.

> > > +	list_t *list = NULL;
> > 
> > Why are you adding another list type when we just merged one into
> > libsepol? If you want this merged into trunk before policyrep let's move
> > the list type over early.
> I'm working off of trunk.  If it isn't in trunk it I can't use it.
> 

I think another list type is unacceptable so you can either work off
policyrep or propose early merging of the list types. Either one is fine
with me.

> <snip>
> > > +	shells = fopen("/etc/shells", "r");
> > > +	if (!shells)
> > > +		return default_shell_list();
> > 
> > See above - when is this error possible and why not make it fatal.
> Again, "it wasn't fatal in genhomedircon"
> 

Dan / anyone - why have the default shell list?

> <snip>
> > > +	setpwent();
> > > +	while ((pwbuf = getpwent())) {
> > 
> > You need to check errno to see if there was an error.
> > 
> > It is not clear from the python docs, but getpwent will definitely pull
> > user entries from LDAP, NIS, etc. Is that what we want or should we
> > limit to /etc/passwd only?
> >From what I've been able to gather, python's getpwall is a wrapper 
> for getpwent. As for whether we want this behavior or not, I'm open 
> to suggestions.
> 

Ok - I'm really just concerned that if we try this against a large LDAP
database things will not go well. Anyone else have an opinion?

> <snip>
> > > +static int fwriteheader(state_t * s, FILE * out)
> > > +{
> > 
> > Needs a better function name.
> Suggestions?
> 

write_file_context_header? Or don't make it a function at all.

> <snip>
> > > +static int write_home_dir_context(FILE * out, list_t * tpl, char *user,
> > > +				  char *seuser, char *home, char *prefix)
> > > +{
> > > +	char *temp;
> > > +	char *line;
> > > +
> > > +	fprintf(out, "\n\n#\n# Home Context for user %s\n#\n\n", user);
> > > +	for (; tpl; tpl = tpl->next) {
> > > +		temp = semanage_sed(tpl->data, "HOME_DIR", home);
> > 
> > Wow - I understand that this string handling in C is painful, but is
> > this really the best alternative? Perhaps parsing the input to make the
> > substitution easier would be better? Perhaps we should look for some
> > library code to do this?
> I am not really sure what the problem with this is.  We need to replace
> arbitrary substrings.  I searched in the C libraries for something that
> might do what I want.  I couldn't find anything, so I wrote a function
> to do it.
> 

This substitution is inefficient and this type of string manipulation in
general is error prone.

> As for parsing the input to make the substitution easier, I think it
> would be a lot more work to write or use a full fledged parser.  What
> we want in this situation is what I wrote in my opinion, although I am
> open to suggestions.
> 
> <snip>
> > > +static int fwriteoutput(state_t * s, FILE * out)
> > > +{
> > 
> > This function name should be more descriptive.
> Suggestions?
> 

Not at the moment - but this is the main entrypoint as far as I can tell
and the name doesn't imply that at all.

> <snip>
> > > +	for (h = homedirs; h; h = h->next) {
> > > +		s1len = strlen(h->data);
> > > +		temp = malloc(s1len + sizeof("/[^/]*"));
> > > +		strcpy(temp, h->data);
> > > +		strcpy(temp + s1len, "/[^/]*");
> > 
> > strdup
> I needed extra space at the end of the string for the suffix, so I malloc'd
> it all in one go.
> 

Ok.

> <snip>
> > > +char *semanage_findval(char *file, char *var, char *delim)
> > > +{
> > > +	FILE *fd;
> > > +
> > > +	char *buff;
> > > +	char *temp = NULL;
> > > +
> > > +	if (!file || !var || !delim)
> > > +		return NULL;
> > 
> > assert?
> As with other things, genhomedircon would not have aborted on this
> condition.  It returned "" on all exceptional paths.
> 

Is it possible for these to be NULL or a sign of an earlier error?

> <snip>
> > > +char *semanage_split(char *str, char *delim)
> > > +{
> > > +	char *temp = str;
> > > +
> > > +	if (!str)
> > > +		return NULL;
> > > +	if (!delim || (*delim == '\0'))
> > > +		return semanage_split_on_space(str);
> > 
> > Having NULL mean space seems odd.
> This function was a python emulation function.  It behaves in the manner
> that python's split would if you don't pass in a delimiter.
> 

I'd prefer things to be more idiomatic to C rather than a straight
python port.

> Consider all unmentioned comments Noted and fixed.
> 

Great.

Karl


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [patch 1/3] libsemanage: genhomedircon replacement

[Daniel J Walsh]

Karl MacMillan wrote:
> On Thu, 2007-05-24 at 10:04 -0400, Mark Goldman wrote:
>   
>> On Tue, 2007-05-22 at 17:08 -0400, Karl MacMillan wrote:
>> <snip>
>>     
>>>> +int semanage_genhomedircon(semanage_handle_t * sh, int usepasswd)
>>>> +{
>>>> +	state_t s;
>>>> +
>>>> +	char outfile[PATH_MAX];
>>>> +	char hdt[PATH_MAX];
>>>> +	char fcf[PATH_MAX];
>>>> +
>>>> +	FILE *out = NULL;
>>>> +	int retval = 0;
>>>> +
>>>> +	assert(sh);
>>>> +
>>>> +	s.homedir_template_path = hdt;
>>>> +	snprintf(s.homedir_template_path, PATH_MAX - 1, "%s",
>>>> +		 semanage_path(SEMANAGE_TMP, SEMANAGE_HOMEDIR_TMPL));
>>>> +
>>>> +	snprintf(outfile, PATH_MAX - 1, "%s",
>>>> +		 semanage_path(SEMANAGE_TMP, SEMANAGE_FC_HOMEDIRS));
>>>> +
>>>>         
>>> strdup?
>>>       
>> The paths are allocated on the stack.  Can't strdup them.  All things being
>> equal, I would prefer to keep them on the stack since that is three
>> fewer items I could possibly leak.
>>
>>     
>
> I think malloc'd would be better because otherwise you have to do this
> fun with PATH_MAX and snprintfs (which is hard to read) and end up with
> a lot of data on the stack. Question - do you even need to copy these?
> Why not just store a pointer to what is returned by semanage_path?
>
>   
>>>> +static list_t *default_shell_list(void)
>>>> +{
>>>>         
>>> What is this function for? Why not error out when /etc/shells is not
>>> available?
>>>       
>> Well, the justification here as with several other places is
>> "genhomedircon didn't".
>>
>>     
>
> I think the behavior should be similar, but there is no reason that we
> can't make changes to corner case behavior if we think it would be
> better. So I don't think an _exact_ port is necessary.
>
>   
>>>> +	list_t *list = NULL;
>>>>         
>>> Why are you adding another list type when we just merged one into
>>> libsepol? If you want this merged into trunk before policyrep let's move
>>> the list type over early.
>>>       
>> I'm working off of trunk.  If it isn't in trunk it I can't use it.
>>
>>     
>
> I think another list type is unacceptable so you can either work off
> policyrep or propose early merging of the list types. Either one is fine
> with me.
>
>   
>> <snip>
>>     
>>>> +	shells = fopen("/etc/shells", "r");
>>>> +	if (!shells)
>>>> +		return default_shell_list();
>>>>         
>>> See above - when is this error possible and why not make it fatal.
>>>       
>> Again, "it wasn't fatal in genhomedircon"
>>
>>     
>
> Dan / anyone - why have the default shell list?
>
>   
Just for the reason stated.  If /etc/shells did not exist, we wanted to 
get a list of valid shells.  I chose not to fail in this case.  But I 
guess failure would be ok.  As long as we told the users how to fix.
>> <snip>
>>     
>>>> +	setpwent();
>>>> +	while ((pwbuf = getpwent())) {
>>>>         
>>> You need to check errno to see if there was an error.
>>>
>>> It is not clear from the python docs, but getpwent will definitely pull
>>> user entries from LDAP, NIS, etc. Is that what we want or should we
>>> limit to /etc/passwd only?
>>>       
>> >From what I've been able to gather, python's getpwall is a wrapper 
>> for getpwent. As for whether we want this behavior or not, I'm open 
>> to suggestions.
>>
>>     
>
> Ok - I'm really just concerned that if we try this against a large LDAP
> database things will not go well. Anyone else have an opinion?
>
>   
I believe ldap has some kind of configuration where it will limit the 
amount of data that can be returned.  (At least that is what Nalin tells me)
>> <snip>
>>     
>>>> +static int fwriteheader(state_t * s, FILE * out)
>>>> +{
>>>>         
>>> Needs a better function name.
>>>       
>> Suggestions?
>>
>>     
>
> write_file_context_header? Or don't make it a function at all.
>
>   
>> <snip>
>>     
>>>> +static int write_home_dir_context(FILE * out, list_t * tpl, char *user,
>>>> +				  char *seuser, char *home, char *prefix)
>>>> +{
>>>> +	char *temp;
>>>> +	char *line;
>>>> +
>>>> +	fprintf(out, "\n\n#\n# Home Context for user %s\n#\n\n", user);
>>>> +	for (; tpl; tpl = tpl->next) {
>>>> +		temp = semanage_sed(tpl->data, "HOME_DIR", home);
>>>>         
>>> Wow - I understand that this string handling in C is painful, but is
>>> this really the best alternative? Perhaps parsing the input to make the
>>> substitution easier would be better? Perhaps we should look for some
>>> library code to do this?
>>>       
>> I am not really sure what the problem with this is.  We need to replace
>> arbitrary substrings.  I searched in the C libraries for something that
>> might do what I want.  I couldn't find anything, so I wrote a function
>> to do it.
>>
>>     
>
> This substitution is inefficient and this type of string manipulation in
> general is error prone.
>
>   
>> As for parsing the input to make the substitution easier, I think it
>> would be a lot more work to write or use a full fledged parser.  What
>> we want in this situation is what I wrote in my opinion, although I am
>> open to suggestions.
>>
>> <snip>
>>     
>>>> +static int fwriteoutput(state_t * s, FILE * out)
>>>> +{
>>>>         
>>> This function name should be more descriptive.
>>>       
>> Suggestions?
>>
>>     
>
> Not at the moment - but this is the main entrypoint as far as I can tell
> and the name doesn't imply that at all.
>
>   
>> <snip>
>>     
>>>> +	for (h = homedirs; h; h = h->next) {
>>>> +		s1len = strlen(h->data);
>>>> +		temp = malloc(s1len + sizeof("/[^/]*"));
>>>> +		strcpy(temp, h->data);
>>>> +		strcpy(temp + s1len, "/[^/]*");
>>>>         
>>> strdup
>>>       
>> I needed extra space at the end of the string for the suffix, so I malloc'd
>> it all in one go.
>>
>>     
>
> Ok.
>
>   
>> <snip>
>>     
>>>> +char *semanage_findval(char *file, char *var, char *delim)
>>>> +{
>>>> +	FILE *fd;
>>>> +
>>>> +	char *buff;
>>>> +	char *temp = NULL;
>>>> +
>>>> +	if (!file || !var || !delim)
>>>> +		return NULL;
>>>>         
>>> assert?
>>>       
>> As with other things, genhomedircon would not have aborted on this
>> condition.  It returned "" on all exceptional paths.
>>
>>     
>
> Is it possible for these to be NULL or a sign of an earlier error?
>
>   
>> <snip>
>>     
>>>> +char *semanage_split(char *str, char *delim)
>>>> +{
>>>> +	char *temp = str;
>>>> +
>>>> +	if (!str)
>>>> +		return NULL;
>>>> +	if (!delim || (*delim == '\0'))
>>>> +		return semanage_split_on_space(str);
>>>>         
>>> Having NULL mean space seems odd.
>>>       
>> This function was a python emulation function.  It behaves in the manner
>> that python's split would if you don't pass in a delimiter.
>>
>>     
>
> I'd prefer things to be more idiomatic to C rather than a straight
> python port.
>
>   
>> Consider all unmentioned comments Noted and fixed.
>>
>>     
>
> Great.
>
> Karl
>
>   


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [patch 1/3] libsemanage: genhomedircon replacement

[Mark Goldman]

On Thu, 2007-05-24 at 10:45 -0400, Karl MacMillan wrote:
> On Thu, 2007-05-24 at 10:04 -0400, Mark Goldman wrote:
> > On Tue, 2007-05-22 at 17:08 -0400, Karl MacMillan wrote:
> > <snip>
> > > > +int semanage_genhomedircon(semanage_handle_t * sh, int usepasswd)
> > > > +{
> > > > +	state_t s;
> > > > +
> > > > +	char outfile[PATH_MAX];
> > > > +	char hdt[PATH_MAX];
> > > > +	char fcf[PATH_MAX];
> > > > +
> > > > +	FILE *out = NULL;
> > > > +	int retval = 0;
> > > > +
> > > > +	assert(sh);
> > > > +
> > > > +	s.homedir_template_path = hdt;
> > > > +	snprintf(s.homedir_template_path, PATH_MAX - 1, "%s",
> > > > +		 semanage_path(SEMANAGE_TMP, SEMANAGE_HOMEDIR_TMPL));
> > > > +
> > > > +	snprintf(outfile, PATH_MAX - 1, "%s",
> > > > +		 semanage_path(SEMANAGE_TMP, SEMANAGE_FC_HOMEDIRS));
> > > > +
> > > 
> > > strdup?
> > The paths are allocated on the stack.  Can't strdup them.  All things being
> > equal, I would prefer to keep them on the stack since that is three
> > fewer items I could possibly leak.
> > 
> 
> I think malloc'd would be better because otherwise you have to do this
> fun with PATH_MAX and snprintfs (which is hard to read) and end up with
> a lot of data on the stack. Question - do you even need to copy these?
> Why not just store a pointer to what is returned by semanage_path?
RE snprintf, I don't think snprintfs are hard to read, I think this is a
style issue.

RE Do I need a copy of these.  Not really, but I didn't want to make
assumptions that the strings would necessarily remain valid.

Fixed: storing the pointers semanage_path() returns instead of copying
them.

> > > > +static list_t *default_shell_list(void)
> > > > +{
> > > 
> > > What is this function for? Why not error out when /etc/shells is not
> > > available?
> > Well, the justification here as with several other places is
> > "genhomedircon didn't".
> > 
> 
> I think the behavior should be similar, but there is no reason that we
> can't make changes to corner case behavior if we think it would be
> better. So I don't think an _exact_ port is necessary.
I didn't know if this particular instance was, in fact, a corner case.
I'd be just as happy for it to error if it is truly a rare condition.
Comments?

> > > > +	list_t *list = NULL;
> > > 
> > > Why are you adding another list type when we just merged one into
> > > libsepol? If you want this merged into trunk before policyrep let's move
> > > the list type over early.
> > I'm working off of trunk.  If it isn't in trunk it I can't use it.
> > 
> 
> I think another list type is unacceptable so you can either work off
> policyrep or propose early merging of the list types. Either one is fine
> with me.
If you would like to move the list types out of policyrep and into
trunk, I'll be happy to use it.  Otherwise it is out of the scope of
this patch.

<snip>
> > > > +char *semanage_findval(char *file, char *var, char *delim)
> > > > +{
> > > > +	FILE *fd;
> > > > +
> > > > +	char *buff;
> > > > +	char *temp = NULL;
> > > > +
> > > > +	if (!file || !var || !delim)
> > > > +		return NULL;
> > > 
> > > assert?
> > As with other things, genhomedircon would not have aborted on this
> > condition.  It returned "" on all exceptional paths.
> > 
> 
> Is it possible for these to be NULL or a sign of an earlier error?
At the moment, the code is never called in a manner where  file or var will
be NULL.  I don't have too strong of an opinion, will assert().

> > <snip>
> > > > +char *semanage_split(char *str, char *delim)
> > > > +{
> > > > +	char *temp = str;
> > > > +
> > > > +	if (!str)
> > > > +		return NULL;
> > > > +	if (!delim || (*delim == '\0'))
> > > > +		return semanage_split_on_space(str);
> > > 
> > > Having NULL mean space seems odd.
> > This function was a python emulation function.  It behaves in the manner
> > that python's split would if you don't pass in a delimiter.
> > 
> 
> I'd prefer things to be more idiomatic to C rather than a straight
> python port.
Noted.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [patch 1/3] libsemanage: genhomedircon replacement

[Karl MacMillan]

On Thu, 2007-05-24 at 15:20 -0400, Mark Goldman wrote:
> On Thu, 2007-05-24 at 10:45 -0400, Karl MacMillan wrote:
> > On Thu, 2007-05-24 at 10:04 -0400, Mark Goldman wrote:
> > > On Tue, 2007-05-22 at 17:08 -0400, Karl MacMillan wrote:

<snip>

> > I think the behavior should be similar, but there is no reason that we
> > can't make changes to corner case behavior if we think it would be
> > better. So I don't think an _exact_ port is necessary.
> I didn't know if this particular instance was, in fact, a corner case.
> I'd be just as happy for it to error if it is truly a rare condition.
> Comments?
> 

I say make it an error but will defer to others.

> > > > > +	list_t *list = NULL;
> > > > 
> > > > Why are you adding another list type when we just merged one into
> > > > libsepol? If you want this merged into trunk before policyrep let's move
> > > > the list type over early.
> > > I'm working off of trunk.  If it isn't in trunk it I can't use it.
> > > 
> > 
> > I think another list type is unacceptable so you can either work off
> > policyrep or propose early merging of the list types. Either one is fine
> > with me.
> If you would like to move the list types out of policyrep and into
> trunk, I'll be happy to use it.  Otherwise it is out of the scope of
> this patch.
> 

Please rebase against the policyrep branch - we can then consider
merging the list types and this patch to trunk if desired. I will NACK
this patch if it contains the additional list types.

Karl


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: [patch 1/3] libsemanage: genhomedircon replacement

[Joshua Brindle]

Karl MacMillan wrote:
> On Thu, 2007-05-24 at 15:20 -0400, Mark Goldman wrote:
>> On Thu, 2007-05-24 at 10:45 -0400, Karl MacMillan wrote:
>>> On Thu, 2007-05-24 at 10:04 -0400, Mark Goldman wrote:
>>>> On Tue, 2007-05-22 at 17:08 -0400, Karl MacMillan wrote:
> 
> <snip>
> 
>>> I think the behavior should be similar, but there is no reason that
>>> we can't make changes to corner case behavior if we think it would
>>> be better. So I don't think an _exact_ port is necessary.
>> I didn't know if this particular instance was, in fact, a corner
>> case. I'd be just as happy for it to error if it is truly a rare
>> condition. Comments? 
>> 
> 
> I say make it an error but will defer to others.
> 
>>>>>> +	list_t *list = NULL;
>>>>> 
>>>>> Why are you adding another list type when we just merged one
>>>>> into libsepol? If you want this merged into trunk before
>>>>> policyrep let's move the list type over early.
>>>> I'm working off of trunk.  If it isn't in trunk it I can't use it.
>>>> 
>>> 
>>> I think another list type is unacceptable so you can either work off
>>> policyrep or propose early merging of the list types. Either one is
>>> fine with me.
>> If you would like to move the list types out of policyrep and into
>> trunk, I'll be happy to use it.  Otherwise it is out of the scope of
>> this patch. 
>> 
> 
> Please rebase against the policyrep branch - we can then
> consider merging the list types and this patch to trunk if
> desired. I will NACK this patch if it contains the additional list
> types. 

There aren't additional list types because there aren't any in trunk.
This has nothing to do with policyrep and doesn't break ABI
compatibility and should be in trunk. I hate this idea of pushing
everything into policyrep because its going to make it that much harder
to get good testing done and the source of bugs will be harder to track
down.

If you are so insistent on using the list types in policyrep why not
port them to trunk so we can use them?


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: [patch 1/3] libsemanage: genhomedircon replacement

[Karl MacMillan]

On Fri, 2007-05-25 at 13:06 -0400, Joshua Brindle wrote:
> Karl MacMillan wrote:
> >> If you would like to move the list types out of policyrep and into
> >> trunk, I'll be happy to use it.  Otherwise it is out of the scope of
> >> this patch. 
> >> 
> > 
> > Please rebase against the policyrep branch - we can then
> > consider merging the list types and this patch to trunk if
> > desired. I will NACK this patch if it contains the additional list
> > types. 
> 
> There aren't additional list types because there aren't any in trunk.
> This has nothing to do with policyrep and doesn't break ABI
> compatibility and should be in trunk. I hate this idea of pushing
> everything into policyrep because its going to make it that much harder
> to get good testing done and the source of bugs will be harder to track
> down.
> 

Ok.

> If you are so insistent on using the list types in policyrep why not
> port them to trunk so we can use them?

That option is fine with me (and was one of my suggestions), though I
don't have time to do the port right now. Can you or Mark send a patch
pulling over the iterators and list?

Karl


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

audit2allow module generation

[Anand Patel]

I am trying to use audit2allow to generate module out of audit messages.

So, I installed refpolicy headers first. Then tried sepolgen-ifgen 

%sepolgen-ifgen
% ... some output ...
%parsing file /usr/share/selinux/devel/include/services/snmp.if
%error parsing file /usr/share/selinux/devel/include/services/snmap.if:
%could not parse text: "Syntax error on line 1 ( [type=OPAREN]"

Parser had problem parsing almost all if files and generated above
error.
It would been helpful if error included correct line number.
Is it parser bug? 
Am I doing anything wrong?
Is there any documentation available on how to use this policy
generation tools?
What are the dependencies these tools have?


Thanks,

Anand Patel
Tresys Technology
apatel@tresys.com
410-290-1411xt153 




--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: audit2allow module generation

[Karl MacMillan]

On Tue, 2007-05-29 at 16:25 -0400, Anand Patel wrote:
> I am trying to use audit2allow to generate module out of audit messages.
> 
> So, I installed refpolicy headers first. Then tried sepolgen-ifgen 
> 
> %sepolgen-ifgen
> % ... some output ...
> %parsing file /usr/share/selinux/devel/include/services/snmp.if
> %error parsing file /usr/share/selinux/devel/include/services/snmap.if:
> %could not parse text: "Syntax error on line 1 ( [type=OPAREN]"
> 
> Parser had problem parsing almost all if files and generated above
> error.

The problem is that the refpolicy "language" is far from fixed and
parsing it cleanly is almost impossible because of M4. So the parser
sometimes gets out of sync with refpolicy (hence the policyrep work).

I just need some more specific information about the refpolicy version
you are using and I should be able to fix-up the parser.

Thanks - Karl

> It would been helpful if error included correct line number.
> Is it parser bug? 
> Am I doing anything wrong?
> Is there any documentation available on how to use this policy
> generation tools?
> What are the dependencies these tools have?
> 
> 
> Thanks,
> 
> Anand Patel
> Tresys Technology
> apatel@tresys.com
> 410-290-1411xt153 
> 
> 


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: audit2allow module generation

[Anand Patel]

> -----Original Message-----
> From: Karl MacMillan [mailto:kmacmillan@mentalrootkit.com]
> Sent: Tuesday, May 29, 2007 5:12 PM
> To: Anand Patel
> Cc: SE Linux; Daniel J Walsh
> Subject: Re: audit2allow module generation
> 
> On Tue, 2007-05-29 at 16:25 -0400, Anand Patel wrote:
> > I am trying to use audit2allow to generate module out of audit
messages.
> >
> > So, I installed refpolicy headers first. Then tried sepolgen-ifgen
> >
> > %sepolgen-ifgen
> > % ... some output ...
> > %parsing file /usr/share/selinux/devel/include/services/snmp.if
> > %error parsing file
/usr/share/selinux/devel/include/services/snmap.if:
> > %could not parse text: "Syntax error on line 1 ( [type=OPAREN]"
> >
> > Parser had problem parsing almost all if files and generated above
> > error.
> 
> The problem is that the refpolicy "language" is far from fixed and
> parsing it cleanly is almost impossible because of M4. So the parser
> sometimes gets out of sync with refpolicy (hence the policyrep work).
> 
> I just need some more specific information about the refpolicy version
> you are using and I should be able to fix-up the parser.

I was using current release from oss.tresys.com/projects/refpolicy.

So, every new version of refpolicy will require tweaks to audit2allow
parser. What tweaks does it require? Where does it fail? Can you give me
some insight of how parser works?

Thanks,


> 
> Thanks - Karl
> 
> > It would been helpful if error included correct line number.
> > Is it parser bug?
> > Am I doing anything wrong?
> > Is there any documentation available on how to use this policy
> > generation tools?
> > What are the dependencies these tools have?
> >
> >
> > Thanks,
> >
> > Anand Patel
> > Tresys Technology
> > apatel@tresys.com
> > 410-290-1411xt153
> >
> >
Anand Patel
Tresys Technology
apatel@tresys.com
410-290-1411xt153


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: audit2allow module generation

[Karl MacMillan]

On Wed, 2007-05-30 at 10:44 -0400, Anand Patel wrote:
> > -----Original Message-----
> > From: Karl MacMillan [mailto:kmacmillan@mentalrootkit.com]
> > Sent: Tuesday, May 29, 2007 5:12 PM
> > To: Anand Patel
> > Cc: SE Linux; Daniel J Walsh
> > Subject: Re: audit2allow module generation
> > 
> > On Tue, 2007-05-29 at 16:25 -0400, Anand Patel wrote:
> > > I am trying to use audit2allow to generate module out of audit
> messages.
> > >
> > > So, I installed refpolicy headers first. Then tried sepolgen-ifgen
> > >
> > > %sepolgen-ifgen
> > > % ... some output ...
> > > %parsing file /usr/share/selinux/devel/include/services/snmp.if
> > > %error parsing file
> /usr/share/selinux/devel/include/services/snmap.if:
> > > %could not parse text: "Syntax error on line 1 ( [type=OPAREN]"
> > >
> > > Parser had problem parsing almost all if files and generated above
> > > error.
> > 
> > The problem is that the refpolicy "language" is far from fixed and
> > parsing it cleanly is almost impossible because of M4. So the parser
> > sometimes gets out of sync with refpolicy (hence the policyrep work).
> > 
> > I just need some more specific information about the refpolicy version
> > you are using and I should be able to fix-up the parser.
> 
> I was using current release from oss.tresys.com/projects/refpolicy.
> 

Ok - Chris, any chance you can start running sepolgen-ifgen on refpolicy
and alerting me to breakage?

> So, every new version of refpolicy will require tweaks to audit2allow
> parser.

No - only when the refpolicy "language" changes (or there is just a new
M4 usage, etc). Basically - I'm trying to parse an informal language
based on M4 which is a pain.

>  What tweaks does it require? Where does it fail? Can you give me
> some insight of how parser works?
> 

See refparser.py in sepolgen.

Karl

> Thanks,
> 
> 
> > 
> > Thanks - Karl
> > 
> > > It would been helpful if error included correct line number.
> > > Is it parser bug?
> > > Am I doing anything wrong?
> > > Is there any documentation available on how to use this policy
> > > generation tools?
> > > What are the dependencies these tools have?
> > >
> > >
> > > Thanks,
> > >
> > > Anand Patel
> > > Tresys Technology
> > > apatel@tresys.com
> > > 410-290-1411xt153
> > >
> > >
> Anand Patel
> Tresys Technology
> apatel@tresys.com
> 410-290-1411xt153


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: audit2allow module generation

[Karl MacMillan]

On Wed, 2007-05-30 at 10:44 -0400, Anand Patel wrote:
> > -----Original Message-----
> > From: Karl MacMillan [mailto:kmacmillan@mentalrootkit.com]
> > Sent: Tuesday, May 29, 2007 5:12 PM
> > To: Anand Patel
> > Cc: SE Linux; Daniel J Walsh
> > Subject: Re: audit2allow module generation
> > 
> > On Tue, 2007-05-29 at 16:25 -0400, Anand Patel wrote:
> > > I am trying to use audit2allow to generate module out of audit
> messages.
> > >
> > > So, I installed refpolicy headers first. Then tried sepolgen-ifgen
> > >
> > > %sepolgen-ifgen
> > > % ... some output ...
> > > %parsing file /usr/share/selinux/devel/include/services/snmp.if
> > > %error parsing file
> /usr/share/selinux/devel/include/services/snmap.if:
> > > %could not parse text: "Syntax error on line 1 ( [type=OPAREN]"
> > >
> > > Parser had problem parsing almost all if files and generated above
> > > error.
> > 
> > The problem is that the refpolicy "language" is far from fixed and
> > parsing it cleanly is almost impossible because of M4. So the parser
> > sometimes gets out of sync with refpolicy (hence the policyrep work).
> > 
> > I just need some more specific information about the refpolicy version
> > you are using and I should be able to fix-up the parser.
> 
> I was using current release from oss.tresys.com/projects/refpolicy.
> 

What version of sepolgen were you using? The latest (in rawhide) seems
to work fine on the latest available refpolicy.

Karl




--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: audit2allow module generation

[Anand Patel]

On Fri, 2007-06-08 at 11:36 -0400, Karl MacMillan wrote:
> On Wed, 2007-05-30 at 10:44 -0400, Anand Patel wrote:
> > > -----Original Message-----
> > > From: Karl MacMillan [mailto:kmacmillan@mentalrootkit.com]
> > > Sent: Tuesday, May 29, 2007 5:12 PM
> > > To: Anand Patel
> > > Cc: SE Linux; Daniel J Walsh
> > > Subject: Re: audit2allow module generation
> > > 
> > > On Tue, 2007-05-29 at 16:25 -0400, Anand Patel wrote:
> > > > I am trying to use audit2allow to generate module out of audit
> > messages.
> > > >
> > > > So, I installed refpolicy headers first. Then tried sepolgen-ifgen
> > > >
> > > > %sepolgen-ifgen
> > > > % ... some output ...
> > > > %parsing file /usr/share/selinux/devel/include/services/snmp.if
> > > > %error parsing file
> > /usr/share/selinux/devel/include/services/snmap.if:
> > > > %could not parse text: "Syntax error on line 1 ( [type=OPAREN]"
> > > >
> > > > Parser had problem parsing almost all if files and generated above
> > > > error.
> > > 
> > > The problem is that the refpolicy "language" is far from fixed and
> > > parsing it cleanly is almost impossible because of M4. So the parser
> > > sometimes gets out of sync with refpolicy (hence the policyrep work).
> > > 
> > > I just need some more specific information about the refpolicy version
> > > you are using and I should be able to fix-up the parser.
> > 
> > I was using current release from oss.tresys.com/projects/refpolicy.
> > 
> 
> What version of sepolgen were you using? The latest (in rawhide) seems
> to work fine on the latest available refpolicy.
Version .1
It seems to work with pristine refpolicy. However, upon modifications to
policy, new macros and moduels, it generates error during interface
index parse.

I am currently investigating where it fails.


> 
> Karl
> 
> 
> 


-- 
Anand Patel
apatel@tresys.com
410-290-1411xt153

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: audit2allow module generation

[Anand Patel]

Karl,

I found that sepol-ifgen parser fails when it sees multiple types in
type declaration statement.
e.g.
	type foo_t, hello_t;
Then I went back and change to following
	type foo_t;
	type hello_t;
and it parsed successfully.

-Anand Patel

-----Original Message-----
From: owner-selinux@tycho.nsa.gov [mailto:owner-selinux@tycho.nsa.gov]
On Behalf Of Anand Patel
Sent: Monday, June 11, 2007 9:48 AM
To: Karl MacMillan
Cc: SE Linux; Daniel J Walsh
Subject: RE: audit2allow module generation

On Fri, 2007-06-08 at 11:36 -0400, Karl MacMillan wrote:
> On Wed, 2007-05-30 at 10:44 -0400, Anand Patel wrote:
> > > -----Original Message-----
> > > From: Karl MacMillan [mailto:kmacmillan@mentalrootkit.com]
> > > Sent: Tuesday, May 29, 2007 5:12 PM
> > > To: Anand Patel
> > > Cc: SE Linux; Daniel J Walsh
> > > Subject: Re: audit2allow module generation
> > > 
> > > On Tue, 2007-05-29 at 16:25 -0400, Anand Patel wrote:
> > > > I am trying to use audit2allow to generate module out of audit
> > messages.
> > > >
> > > > So, I installed refpolicy headers first. Then tried
sepolgen-ifgen
> > > >
> > > > %sepolgen-ifgen
> > > > % ... some output ...
> > > > %parsing file /usr/share/selinux/devel/include/services/snmp.if
> > > > %error parsing file
> > /usr/share/selinux/devel/include/services/snmap.if:
> > > > %could not parse text: "Syntax error on line 1 ( [type=OPAREN]"
> > > >
> > > > Parser had problem parsing almost all if files and generated
above
> > > > error.
> > > 
> > > The problem is that the refpolicy "language" is far from fixed and
> > > parsing it cleanly is almost impossible because of M4. So the
parser
> > > sometimes gets out of sync with refpolicy (hence the policyrep
work).
> > > 
> > > I just need some more specific information about the refpolicy
version
> > > you are using and I should be able to fix-up the parser.
> > 
> > I was using current release from oss.tresys.com/projects/refpolicy.
> > 
> 
> What version of sepolgen were you using? The latest (in rawhide) seems
> to work fine on the latest available refpolicy.
Version .1
It seems to work with pristine refpolicy. However, upon modifications to
policy, new macros and moduels, it generates error during interface
index parse.

I am currently investigating where it fails.


> 
> Karl
> 
> 
> 


-- 
Anand Patel
apatel@tresys.com
410-290-1411xt153

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov
with
the words "unsubscribe selinux" without quotes as the message.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: audit2allow module generation

[Karl MacMillan]

On Thu, 2007-08-30 at 09:43 -0400, Anand Patel wrote:
> Karl,
> 
> I found that sepol-ifgen parser fails when it sees multiple types in
> type declaration statement.
> e.g.
> 	type foo_t, hello_t;

This isn't a valid way to define two types - you are instead defining
the type foo_t with the attribute hello_t. It's an easy mistake to make
because of the similarity to the require syntax for requiring multiple
types.

I'm sending a large update to the parser soon that will fix this problem
though.

Karl

> Then I went back and change to following
> 	type foo_t;
> 	type hello_t;
> and it parsed successfully.
> 
> -Anand Patel
> 
> -----Original Message-----
> From: owner-selinux@tycho.nsa.gov [mailto:owner-selinux@tycho.nsa.gov]
> On Behalf Of Anand Patel
> Sent: Monday, June 11, 2007 9:48 AM
> To: Karl MacMillan
> Cc: SE Linux; Daniel J Walsh
> Subject: RE: audit2allow module generation
> 
> On Fri, 2007-06-08 at 11:36 -0400, Karl MacMillan wrote:
> > On Wed, 2007-05-30 at 10:44 -0400, Anand Patel wrote:
> > > > -----Original Message-----
> > > > From: Karl MacMillan [mailto:kmacmillan@mentalrootkit.com]
> > > > Sent: Tuesday, May 29, 2007 5:12 PM
> > > > To: Anand Patel
> > > > Cc: SE Linux; Daniel J Walsh
> > > > Subject: Re: audit2allow module generation
> > > > 
> > > > On Tue, 2007-05-29 at 16:25 -0400, Anand Patel wrote:
> > > > > I am trying to use audit2allow to generate module out of audit
> > > messages.
> > > > >
> > > > > So, I installed refpolicy headers first. Then tried
> sepolgen-ifgen
> > > > >
> > > > > %sepolgen-ifgen
> > > > > % ... some output ...
> > > > > %parsing file /usr/share/selinux/devel/include/services/snmp.if
> > > > > %error parsing file
> > > /usr/share/selinux/devel/include/services/snmap.if:
> > > > > %could not parse text: "Syntax error on line 1 ( [type=OPAREN]"
> > > > >
> > > > > Parser had problem parsing almost all if files and generated
> above
> > > > > error.
> > > > 
> > > > The problem is that the refpolicy "language" is far from fixed and
> > > > parsing it cleanly is almost impossible because of M4. So the
> parser
> > > > sometimes gets out of sync with refpolicy (hence the policyrep
> work).
> > > > 
> > > > I just need some more specific information about the refpolicy
> version
> > > > you are using and I should be able to fix-up the parser.
> > > 
> > > I was using current release from oss.tresys.com/projects/refpolicy.
> > > 
> > 
> > What version of sepolgen were you using? The latest (in rawhide) seems
> > to work fine on the latest available refpolicy.
> Version .1
> It seems to work with pristine refpolicy. However, upon modifications to
> policy, new macros and moduels, it generates error during interface
> index parse.
> 
> I am currently investigating where it fails.
> 
> 
> > 
> > Karl
> > 
> > 
> > 
> 
> 


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: audit2allow module generation

[Anand Patel]

How do I generate perm_map file for audit2allow?

Thanks
-Anand Patel


> -----Original Message-----
> From: Karl MacMillan [mailto:kmacmillan@mentalrootkit.com]
> Sent: Monday, September 03, 2007 12:14 PM
> To: Anand Patel
> Cc: SE Linux
> Subject: RE: audit2allow module generation
> 
> On Thu, 2007-08-30 at 09:43 -0400, Anand Patel wrote:
> > Karl,
> >
> > I found that sepol-ifgen parser fails when it sees multiple types in
> > type declaration statement.
> > e.g.
> > 	type foo_t, hello_t;
> 
> This isn't a valid way to define two types - you are instead defining
> the type foo_t with the attribute hello_t. It's an easy mistake to
make
> because of the similarity to the require syntax for requiring multiple
> types.
> 
> I'm sending a large update to the parser soon that will fix this
problem
> though.
> 
> Karl
> 
> > Then I went back and change to following
> > 	type foo_t;
> > 	type hello_t;
> > and it parsed successfully.
> >
> > -Anand Patel
> >
> > -----Original Message-----
> > From: owner-selinux@tycho.nsa.gov
[mailto:owner-selinux@tycho.nsa.gov]
> > On Behalf Of Anand Patel
> > Sent: Monday, June 11, 2007 9:48 AM
> > To: Karl MacMillan
> > Cc: SE Linux; Daniel J Walsh
> > Subject: RE: audit2allow module generation
> >
> > On Fri, 2007-06-08 at 11:36 -0400, Karl MacMillan wrote:
> > > On Wed, 2007-05-30 at 10:44 -0400, Anand Patel wrote:
> > > > > -----Original Message-----
> > > > > From: Karl MacMillan [mailto:kmacmillan@mentalrootkit.com]
> > > > > Sent: Tuesday, May 29, 2007 5:12 PM
> > > > > To: Anand Patel
> > > > > Cc: SE Linux; Daniel J Walsh
> > > > > Subject: Re: audit2allow module generation
> > > > >
> > > > > On Tue, 2007-05-29 at 16:25 -0400, Anand Patel wrote:
> > > > > > I am trying to use audit2allow to generate module out of
audit
> > > > messages.
> > > > > >
> > > > > > So, I installed refpolicy headers first. Then tried
> > sepolgen-ifgen
> > > > > >
> > > > > > %sepolgen-ifgen
> > > > > > % ... some output ...
> > > > > > %parsing file
/usr/share/selinux/devel/include/services/snmp.if
> > > > > > %error parsing file
> > > > /usr/share/selinux/devel/include/services/snmap.if:
> > > > > > %could not parse text: "Syntax error on line 1 (
[type=OPAREN]"
> > > > > >
> > > > > > Parser had problem parsing almost all if files and generated
> > above
> > > > > > error.
> > > > >
> > > > > The problem is that the refpolicy "language" is far from fixed
and
> > > > > parsing it cleanly is almost impossible because of M4. So the
> > parser
> > > > > sometimes gets out of sync with refpolicy (hence the policyrep
> > work).
> > > > >
> > > > > I just need some more specific information about the refpolicy
> > version
> > > > > you are using and I should be able to fix-up the parser.
> > > >
> > > > I was using current release from
oss.tresys.com/projects/refpolicy.
> > > >
> > >
> > > What version of sepolgen were you using? The latest (in rawhide)
seems
> > > to work fine on the latest available refpolicy.
> > Version .1
> > It seems to work with pristine refpolicy. However, upon
modifications to
> > policy, new macros and moduels, it generates error during interface
> > index parse.
> >
> > I am currently investigating where it fails.
> >
> >
> > >
> > > Karl
> > >
> > >
> > >
> >
> >



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: audit2allow module generation

[Karl MacMillan]

On Mon, 2007-09-10 at 10:10 -0400, Anand Patel wrote:
> How do I generate perm_map file for audit2allow?
> 

You shouldn't need to - one is provided. What prompted you to ask?

Karl

> Thanks
> -Anand Patel
> 
> 
> > -----Original Message-----
> > From: Karl MacMillan [mailto:kmacmillan@mentalrootkit.com]
> > Sent: Monday, September 03, 2007 12:14 PM
> > To: Anand Patel
> > Cc: SE Linux
> > Subject: RE: audit2allow module generation
> > 
> > On Thu, 2007-08-30 at 09:43 -0400, Anand Patel wrote:
> > > Karl,
> > >
> > > I found that sepol-ifgen parser fails when it sees multiple types in
> > > type declaration statement.
> > > e.g.
> > > 	type foo_t, hello_t;
> > 
> > This isn't a valid way to define two types - you are instead defining
> > the type foo_t with the attribute hello_t. It's an easy mistake to
> make
> > because of the similarity to the require syntax for requiring multiple
> > types.
> > 
> > I'm sending a large update to the parser soon that will fix this
> problem
> > though.
> > 
> > Karl
> > 
> > > Then I went back and change to following
> > > 	type foo_t;
> > > 	type hello_t;
> > > and it parsed successfully.
> > >
> > > -Anand Patel
> > >
> > > -----Original Message-----
> > > From: owner-selinux@tycho.nsa.gov
> [mailto:owner-selinux@tycho.nsa.gov]
> > > On Behalf Of Anand Patel
> > > Sent: Monday, June 11, 2007 9:48 AM
> > > To: Karl MacMillan
> > > Cc: SE Linux; Daniel J Walsh
> > > Subject: RE: audit2allow module generation
> > >
> > > On Fri, 2007-06-08 at 11:36 -0400, Karl MacMillan wrote:
> > > > On Wed, 2007-05-30 at 10:44 -0400, Anand Patel wrote:
> > > > > > -----Original Message-----
> > > > > > From: Karl MacMillan [mailto:kmacmillan@mentalrootkit.com]
> > > > > > Sent: Tuesday, May 29, 2007 5:12 PM
> > > > > > To: Anand Patel
> > > > > > Cc: SE Linux; Daniel J Walsh
> > > > > > Subject: Re: audit2allow module generation
> > > > > >
> > > > > > On Tue, 2007-05-29 at 16:25 -0400, Anand Patel wrote:
> > > > > > > I am trying to use audit2allow to generate module out of
> audit
> > > > > messages.
> > > > > > >
> > > > > > > So, I installed refpolicy headers first. Then tried
> > > sepolgen-ifgen
> > > > > > >
> > > > > > > %sepolgen-ifgen
> > > > > > > % ... some output ...
> > > > > > > %parsing file
> /usr/share/selinux/devel/include/services/snmp.if
> > > > > > > %error parsing file
> > > > > /usr/share/selinux/devel/include/services/snmap.if:
> > > > > > > %could not parse text: "Syntax error on line 1 (
> [type=OPAREN]"
> > > > > > >
> > > > > > > Parser had problem parsing almost all if files and generated
> > > above
> > > > > > > error.
> > > > > >
> > > > > > The problem is that the refpolicy "language" is far from fixed
> and
> > > > > > parsing it cleanly is almost impossible because of M4. So the
> > > parser
> > > > > > sometimes gets out of sync with refpolicy (hence the policyrep
> > > work).
> > > > > >
> > > > > > I just need some more specific information about the refpolicy
> > > version
> > > > > > you are using and I should be able to fix-up the parser.
> > > > >
> > > > > I was using current release from
> oss.tresys.com/projects/refpolicy.
> > > > >
> > > >
> > > > What version of sepolgen were you using? The latest (in rawhide)
> seems
> > > > to work fine on the latest available refpolicy.
> > > Version .1
> > > It seems to work with pristine refpolicy. However, upon
> modifications to
> > > policy, new macros and moduels, it generates error during interface
> > > index parse.
> > >
> > > I am currently investigating where it fails.
> > >
> > >
> > > >
> > > > Karl
> > > >
> > > >
> > > >
> > >
> > >
> 


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [patch 1/3] libsemanage: genhomedircon replacement

[Joshua Brindle]

Karl MacMillan wrote:
> On Fri, 2007-05-25 at 13:06 -0400, Joshua Brindle wrote:
>> Karl MacMillan wrote:
>>>> If you would like to move the list types out of policyrep and into
>>>> trunk, I'll be happy to use it.  Otherwise it is out of the scope of
>>>> this patch. 
>>>>
>>> Please rebase against the policyrep branch - we can then
>>> consider merging the list types and this patch to trunk if
>>> desired. I will NACK this patch if it contains the additional list
>>> types. 
>> There aren't additional list types because there aren't any in trunk.
>> This has nothing to do with policyrep and doesn't break ABI
>> compatibility and should be in trunk. I hate this idea of pushing
>> everything into policyrep because its going to make it that much harder
>> to get good testing done and the source of bugs will be harder to track
>> down.
>>
> 
> Ok.
> 
>> If you are so insistent on using the list types in policyrep why not
>> port them to trunk so we can use them?
> 
> That option is fine with me (and was one of my suggestions), though I
> don't have time to do the port right now. Can you or Mark send a patch
> pulling over the iterators and list?

I'm going to bring this back up because I think this patch is important 
to get into upstream as a first step toward generic label generation.

Since we aren't using the policyrep branch anymore and libpolicyrep is 
going to be in c++ do you still have reservations against this patch?


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [patch 1/3] libsemanage: genhomedircon replacement

[Karl MacMillan]

On Tue, 2007-06-19 at 11:09 -0400, Joshua Brindle wrote:
> Karl MacMillan wrote:
> > On Fri, 2007-05-25 at 13:06 -0400, Joshua Brindle wrote:
> >> Karl MacMillan wrote:
> >>>> If you would like to move the list types out of policyrep and into
> >>>> trunk, I'll be happy to use it.  Otherwise it is out of the scope of
> >>>> this patch. 
> >>>>
> >>> Please rebase against the policyrep branch - we can then
> >>> consider merging the list types and this patch to trunk if
> >>> desired. I will NACK this patch if it contains the additional list
> >>> types. 
> >> There aren't additional list types because there aren't any in trunk.
> >> This has nothing to do with policyrep and doesn't break ABI
> >> compatibility and should be in trunk. I hate this idea of pushing
> >> everything into policyrep because its going to make it that much harder
> >> to get good testing done and the source of bugs will be harder to track
> >> down.
> >>
> > 
> > Ok.
> > 
> >> If you are so insistent on using the list types in policyrep why not
> >> port them to trunk so we can use them?
> > 
> > That option is fine with me (and was one of my suggestions), though I
> > don't have time to do the port right now. Can you or Mark send a patch
> > pulling over the iterators and list?
> 
> I'm going to bring this back up because I think this patch is important 
> to get into upstream as a first step toward generic label generation.
> 

Can you tell me a little more about what you are thinking with this?

> Since we aren't using the policyrep branch anymore and libpolicyrep is 
> going to be in c++ do you still have reservations against this patch?
> 

I'm still convinced about the maintenance long term and potential for
errors. Have all of the implementation issues that James brought up been
resolved? Remind me why this is better in C than in an external Python
helper.

Karl


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: [patch 1/3] libsemanage: genhomedircon replacement

[Joshua Brindle]

Karl MacMillan wrote:
> On Tue, 2007-06-19 at 11:09 -0400, Joshua Brindle wrote:
>> Karl MacMillan wrote:
>>> On Fri, 2007-05-25 at 13:06 -0400, Joshua Brindle wrote:
>>>> Karl MacMillan wrote:
>>>>>> If you would like to move the list types out of policyrep and
>>>>>> into trunk, I'll be happy to use it.  Otherwise it is out of the
>>>>>> scope of this patch. 
>>>>>> 
>>>>> Please rebase against the policyrep branch - we can then consider
>>>>> merging the list types and this patch to trunk if desired. I will
>>>>> NACK this patch if it contains the additional list types.
>>>> There aren't additional list types because there aren't any in
>>>> trunk. This has nothing to do with policyrep and doesn't break ABI
>>>> compatibility and should be in trunk. I hate this idea of pushing
>>>> everything into policyrep because its going to make it that much
>>>> harder to get good testing done and the source of bugs will be
>>>> harder to track down. 
>>>> 
>>> 
>>> Ok.
>>> 
>>>> If you are so insistent on using the list types in policyrep why
>>>> not port them to trunk so we can use them?
>>> 
>>> That option is fine with me (and was one of my suggestions), though
>>> I don't have time to do the port right now. Can you or Mark send a
>>> patch pulling over the iterators and list?
>> 
>> I'm going to bring this back up because I think this patch is
>> important to get into upstream as a first step toward generic label
>> generation. 
>> 
> 
> Can you tell me a little more about what you are thinking with this?
> 
>> Since we aren't using the policyrep branch anymore and libpolicyrep
>> is going to be in c++ do you still have reservations against this
>> patch? 
>> 
> 
> I'm still convinced about the maintenance long term and
> potential for errors. Have all of the implementation issues
> that James brought up been resolved? Remind me why this is
> better in C than in an external Python helper.
> 

Its very hacky, we have to close the current transaction (from within
the library) so that genhomedircon can connect and get a read lock on
the newly created active store and then it modifies the files outside of
the module store, non-ideal in almost every way.





--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: [patch 1/3] libsemanage: genhomedircon replacement

[Karl MacMillan]

On Thu, 2007-06-21 at 12:49 -0400, Joshua Brindle wrote:
> Karl MacMillan wrote:
> > On Tue, 2007-06-19 at 11:09 -0400, Joshua Brindle wrote:
> >> Karl MacMillan wrote:
> >>> On Fri, 2007-05-25 at 13:06 -0400, Joshua Brindle wrote:
> >>>> Karl MacMillan wrote:
> >>>>>> If you would like to move the list types out of policyrep and
> >>>>>> into trunk, I'll be happy to use it.  Otherwise it is out of the
> >>>>>> scope of this patch. 
> >>>>>> 
> >>>>> Please rebase against the policyrep branch - we can then consider
> >>>>> merging the list types and this patch to trunk if desired. I will
> >>>>> NACK this patch if it contains the additional list types.
> >>>> There aren't additional list types because there aren't any in
> >>>> trunk. This has nothing to do with policyrep and doesn't break ABI
> >>>> compatibility and should be in trunk. I hate this idea of pushing
> >>>> everything into policyrep because its going to make it that much
> >>>> harder to get good testing done and the source of bugs will be
> >>>> harder to track down. 
> >>>> 
> >>> 
> >>> Ok.
> >>> 
> >>>> If you are so insistent on using the list types in policyrep why
> >>>> not port them to trunk so we can use them?
> >>> 
> >>> That option is fine with me (and was one of my suggestions), though
> >>> I don't have time to do the port right now. Can you or Mark send a
> >>> patch pulling over the iterators and list?
> >> 
> >> I'm going to bring this back up because I think this patch is
> >> important to get into upstream as a first step toward generic label
> >> generation. 
> >> 
> > 
> > Can you tell me a little more about what you are thinking with this?
> > 

??

> >> Since we aren't using the policyrep branch anymore and libpolicyrep
> >> is going to be in c++ do you still have reservations against this
> >> patch? 
> >> 
> > 
> > I'm still convinced about the maintenance long term and
> > potential for errors. Have all of the implementation issues
> > that James brought up been resolved? Remind me why this is
> > better in C than in an external Python helper.
> > 
> 
> Its very hacky, we have to close the current transaction (from within
> the library) so that genhomedircon can connect and get a read lock on
> the newly created active store and then it modifies the files outside of
> the module store, non-ideal in almost every way.
> 

Why does it need to get the read lock - why can't it be changed to take
the sandbox location and work on that directly? Fixing that might be
better long term as it seems advantageous to allow helper programs in
general (for separation and least-privilege).

Karl



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: [patch 1/3] libsemanage: genhomedircon replacement

[Joshua Brindle]

Karl MacMillan wrote:
> On Thu, 2007-06-21 at 12:49 -0400, Joshua Brindle wrote:
>> Karl MacMillan wrote:
>>> On Tue, 2007-06-19 at 11:09 -0400, Joshua Brindle wrote:
>>>> Karl MacMillan wrote:
>>>>> On Fri, 2007-05-25 at 13:06 -0400, Joshua Brindle wrote:
>>>>>> Karl MacMillan wrote:
>>>>>>>> If you would like to move the list types out of policyrep and
>>>>>>>> into trunk, I'll be happy to use it.  Otherwise it is out of
>>>>>>>> the scope of this patch. 
>>>>>>>> 
>>>>>>> Please rebase against the policyrep branch - we can then
>>>>>>> consider merging the list types and this patch to trunk if
>>>>>>> desired. I will NACK this patch if it contains the
> additional list types.
>>>>>> There aren't additional list types because there aren't any in
>>>>>> trunk. This has nothing to do with policyrep and doesn't break
>>>>>> ABI compatibility and should be in trunk. I hate this idea of
>>>>>> pushing everything into policyrep because its going to make it
>>>>>> that much harder to get good testing done and the source of bugs
>>>>>> will be harder to track down. 
>>>>>> 
>>>>> 
>>>>> Ok.
>>>>> 
>>>>>> If you are so insistent on using the list types in policyrep why
>>>>>> not port them to trunk so we can use them?
>>>>> 
>>>>> That option is fine with me (and was one of my suggestions),
>>>>> though I don't have time to do the port right now. Can you or Mark
>>>>> send a patch pulling over the iterators and list?
>>>> 
>>>> I'm going to bring this back up because I think this patch is
>>>> important to get into upstream as a first step toward generic
>>>> label generation. 
>>>> 
>>> 
>>> Can you tell me a little more about what you are thinking with this?
>>> 
> 
> ??
> 

We need labels for various object managers (like policy server)
generated per user. For example, if you look back at the PoC apache
metapolicy you'll see some hardcoded labels like user_apache_types_t and
so on, these need to be generated for each user. 


>>>> Since we aren't using the policyrep branch anymore and libpolicyrep
>>>> is going to be in c++ do you still have reservations against this
>>>> patch? 
>>>> 
>>> 
>>> I'm still convinced about the maintenance long term and potential
>>> for errors. Have all of the implementation issues that James brought
>>> up been resolved? Remind me why this is better in C than in an
>>> external Python helper. 
>>> 
>> 
>> Its very hacky, we have to close the current transaction (from within
>> the library) so that genhomedircon can connect and get a read lock on
>> the newly created active store and then it modifies the files outside
>> of the module store, non-ideal in almost every way.
>> 
> 
> Why does it need to get the read lock - why can't it be
> changed to take the sandbox location and work on that
> directly? Fixing that might be better long term as it seems
> advantageous to allow helper programs in general (for
> separation and least-privilege).
> 

Work directly on the module store? The module store is a private
resource of libsemanage, applications should not modify it directly
outside of libsemanage. The least-priv argument is nonsense since
semodule/semanage/setsebool always have to be able to generate
everything in the module store and copy them all out to the filesystem,
making genhomedircon separate serves no purpose in that regard.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: [patch 1/3] libsemanage: genhomedircon replacement

[Karl MacMillan]

On Thu, 2007-06-21 at 14:09 -0400, Joshua Brindle wrote:
> Karl MacMillan wrote:
> > On Thu, 2007-06-21 at 12:49 -0400, Joshua Brindle wrote:
> >> Karl MacMillan wrote:
> >>> On Tue, 2007-06-19 at 11:09 -0400, Joshua Brindle wrote:
> >>>> Karl MacMillan wrote:
> >>>>> On Fri, 2007-05-25 at 13:06 -0400, Joshua Brindle wrote:
> >>>>>> Karl MacMillan wrote:
> >>>>>>>> If you would like to move the list types out of policyrep and
> >>>>>>>> into trunk, I'll be happy to use it.  Otherwise it is out of
> >>>>>>>> the scope of this patch. 
> >>>>>>>> 
> >>>>>>> Please rebase against the policyrep branch - we can then
> >>>>>>> consider merging the list types and this patch to trunk if
> >>>>>>> desired. I will NACK this patch if it contains the
> > additional list types.
> >>>>>> There aren't additional list types because there aren't any in
> >>>>>> trunk. This has nothing to do with policyrep and doesn't break
> >>>>>> ABI compatibility and should be in trunk. I hate this idea of
> >>>>>> pushing everything into policyrep because its going to make it
> >>>>>> that much harder to get good testing done and the source of bugs
> >>>>>> will be harder to track down. 
> >>>>>> 
> >>>>> 
> >>>>> Ok.
> >>>>> 
> >>>>>> If you are so insistent on using the list types in policyrep why
> >>>>>> not port them to trunk so we can use them?
> >>>>> 
> >>>>> That option is fine with me (and was one of my suggestions),
> >>>>> though I don't have time to do the port right now. Can you or Mark
> >>>>> send a patch pulling over the iterators and list?
> >>>> 
> >>>> I'm going to bring this back up because I think this patch is
> >>>> important to get into upstream as a first step toward generic
> >>>> label generation. 
> >>>> 
> >>> 
> >>> Can you tell me a little more about what you are thinking with this?
> >>> 
> > 
> > ??
> > 
> 
> We need labels for various object managers (like policy server)
> generated per user. For example, if you look back at the PoC apache
> metapolicy you'll see some hardcoded labels like user_apache_types_t and
> so on, these need to be generated for each user. 
> 
> 
> >>>> Since we aren't using the policyrep branch anymore and libpolicyrep
> >>>> is going to be in c++ do you still have reservations against this
> >>>> patch? 
> >>>> 
> >>> 
> >>> I'm still convinced about the maintenance long term and potential
> >>> for errors. Have all of the implementation issues that James brought
> >>> up been resolved? Remind me why this is better in C than in an
> >>> external Python helper. 
> >>> 
> >> 
> >> Its very hacky, we have to close the current transaction (from within
> >> the library) so that genhomedircon can connect and get a read lock on
> >> the newly created active store and then it modifies the files outside
> >> of the module store, non-ideal in almost every way.
> >> 
> > 
> > Why does it need to get the read lock - why can't it be
> > changed to take the sandbox location and work on that
> > directly? Fixing that might be better long term as it seems
> > advantageous to allow helper programs in general (for
> > separation and least-privilege).
> > 
> 
> Work directly on the module store? The module store is a private
> resource of libsemanage, applications should not modify it directly
> outside of libsemanage.

genhomedircon is part of libsemanage - it just runs in a separate
process. IOW it is just an implementation detail.

>  The least-priv argument is nonsense since
> semodule/semanage/setsebool always have to be able to generate
> everything in the module store and copy them all out to the filesystem,
> making genhomedircon separate serves no purpose in that regard.

Think about a process to verify untrusted data (like modules) - it would
be helpful to allow a separate process to examine that data. Yes things
like semodule will have full access but allowing a lower-privileged
process to handle some parts is desirable in my opinion.

Karl


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: [patch 1/3] libsemanage: genhomedircon replacement

[Joshua Brindle]

Karl MacMillan wrote:
> On Thu, 2007-06-21 at 14:09 -0400, Joshua Brindle wrote:
>> Karl MacMillan wrote:
>>> On Thu, 2007-06-21 at 12:49 -0400, Joshua Brindle wrote:
>>>> Karl MacMillan wrote:
>>>>> On Tue, 2007-06-19 at 11:09 -0400, Joshua Brindle wrote:
>>>>>> Karl MacMillan wrote:
>>>>>>> On Fri, 2007-05-25 at 13:06 -0400, Joshua Brindle wrote:
>>>>>>>> Karl MacMillan wrote:
>>>>>>>>>> If you would like to move the list types out of policyrep and
>>>>>>>>>> into trunk, I'll be happy to use it.  Otherwise it is out of
>>>>>>>>>> the scope of this patch. 
>>>>>>>>>> 
>>>>>>>>> Please rebase against the policyrep branch - we can then
>>>>>>>>> consider merging the list types and this patch to trunk if
>>>>>>>>> desired. I will NACK this patch if it contains the
>>> additional list types.
>>>>>>>> There aren't additional list types because there aren't any in
>>>>>>>> trunk. This has nothing to do with policyrep and doesn't break
>>>>>>>> ABI compatibility and should be in trunk. I hate this idea of
>>>>>>>> pushing everything into policyrep because its going to make it
>>>>>>>> that much harder to get good testing done and the source of
>>>>>>>> bugs will be harder to track down.
>>>>>>>> 
>>>>>>> 
>>>>>>> Ok.
>>>>>>> 
>>>>>>>> If you are so insistent on using the list types in policyrep
>>>>>>>> why not port them to trunk so we can use them?
>>>>>>> 
>>>>>>> That option is fine with me (and was one of my suggestions),
>>>>>>> though I don't have time to do the port right now. Can you or
>>>>>>> Mark send a patch pulling over the iterators and list?
>>>>>> 
>>>>>> I'm going to bring this back up because I think this patch is
>>>>>> important to get into upstream as a first step toward generic
>>>>>> label generation. 
>>>>>> 
>>>>> 
>>>>> Can you tell me a little more about what you are thinking with
>>>>> this? 
>>>>> 
>>> 
>>> ??
>>> 
>> 
>> We need labels for various object managers (like policy server)
>> generated per user. For example, if you look back at the PoC apache
>> metapolicy you'll see some hardcoded labels like user_apache_types_t
>> and so on, these need to be generated for each user.
>> 
>> 
>>>>>> Since we aren't using the policyrep branch anymore and
>>>>>> libpolicyrep is going to be in c++ do you still have
>>>>>> reservations against this patch? 
>>>>>> 
>>>>> 
>>>>> I'm still convinced about the maintenance long term and potential
>>>>> for errors. Have all of the implementation issues that James
>>>>> brought up been resolved? Remind me why this is better in C than
>>>>> in an external Python helper. 
>>>>> 
>>>> 
>>>> Its very hacky, we have to close the current transaction (from
>>>> within the library) so that genhomedircon can connect and get a
>>>> read lock on the newly created active store and then it modifies
>>>> the files outside of the module store, non-ideal in almost every
>>>> way. 
>>>> 
>>> 
>>> Why does it need to get the read lock - why can't it be changed to
>>> take the sandbox location and work on that directly? Fixing that
>>> might be better long term as it seems advantageous to allow helper
>>> programs in general (for separation and least-privilege).
>>> 
>> 
>> Work directly on the module store? The module store is a private
>> resource of libsemanage, applications should not modify it directly
>> outside of libsemanage.
> 
> genhomedircon is part of libsemanage - it just runs in a
> separate process. IOW it is just an implementation detail.
> 

Not to mention running a python interpreter from a library is pretty
lame. How is this any worse than the other craziness that is
libsemanage?

>>  The least-priv argument is nonsense since
>> semodule/semanage/setsebool always have to be able to generate
>> everything in the module store and copy them all out to the
>> filesystem, making genhomedircon separate serves no purpose in that
>> regard. 
> 
> Think about a process to verify untrusted data (like modules)
> - it would be helpful to allow a separate process to examine
> that data. Yes things like semodule will have full access but
> allowing a lower-privileged process to handle some parts is desirable
> in my opinion. 

We already have a facility to run external apps that can do that. In
semanage.conf just do:

[verify module]
path=/some/path/to/checker
[end]

Which has nothing to do with genhomedircon, genhomedircon is mutating
the store, we should not be providing a facility to let random programs
mutate the store arbitrarilly.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: [patch 1/3] libsemanage: genhomedircon replacement

[Karl MacMillan]

On Thu, 2007-06-21 at 14:25 -0400, Joshua Brindle wrote:
> Karl MacMillan wrote:
> > On Thu, 2007-06-21 at 14:09 -0400, Joshua Brindle wrote:
> >> Karl MacMillan wrote:
> >>> On Thu, 2007-06-21 at 12:49 -0400, Joshua Brindle wrote:
> >>>> Karl MacMillan wrote:
> >>>>> On Tue, 2007-06-19 at 11:09 -0400, Joshua Brindle wrote:
> >>>>>> Karl MacMillan wrote:
> >>>>>>> On Fri, 2007-05-25 at 13:06 -0400, Joshua Brindle wrote:
> >>>>>>>> Karl MacMillan wrote:
> >>>>>>>>>> If you would like to move the list types out of policyrep and
> >>>>>>>>>> into trunk, I'll be happy to use it.  Otherwise it is out of
> >>>>>>>>>> the scope of this patch. 
> >>>>>>>>>> 
> >>>>>>>>> Please rebase against the policyrep branch - we can then
> >>>>>>>>> consider merging the list types and this patch to trunk if
> >>>>>>>>> desired. I will NACK this patch if it contains the
> >>> additional list types.
> >>>>>>>> There aren't additional list types because there aren't any in
> >>>>>>>> trunk. This has nothing to do with policyrep and doesn't break
> >>>>>>>> ABI compatibility and should be in trunk. I hate this idea of
> >>>>>>>> pushing everything into policyrep because its going to make it
> >>>>>>>> that much harder to get good testing done and the source of
> >>>>>>>> bugs will be harder to track down.
> >>>>>>>> 
> >>>>>>> 
> >>>>>>> Ok.
> >>>>>>> 
> >>>>>>>> If you are so insistent on using the list types in policyrep
> >>>>>>>> why not port them to trunk so we can use them?
> >>>>>>> 
> >>>>>>> That option is fine with me (and was one of my suggestions),
> >>>>>>> though I don't have time to do the port right now. Can you or
> >>>>>>> Mark send a patch pulling over the iterators and list?
> >>>>>> 
> >>>>>> I'm going to bring this back up because I think this patch is
> >>>>>> important to get into upstream as a first step toward generic
> >>>>>> label generation. 
> >>>>>> 
> >>>>> 
> >>>>> Can you tell me a little more about what you are thinking with
> >>>>> this? 
> >>>>> 
> >>> 
> >>> ??
> >>> 
> >> 
> >> We need labels for various object managers (like policy server)
> >> generated per user. For example, if you look back at the PoC apache
> >> metapolicy you'll see some hardcoded labels like user_apache_types_t
> >> and so on, these need to be generated for each user.
> >> 
> >> 
> >>>>>> Since we aren't using the policyrep branch anymore and
> >>>>>> libpolicyrep is going to be in c++ do you still have
> >>>>>> reservations against this patch? 
> >>>>>> 
> >>>>> 
> >>>>> I'm still convinced about the maintenance long term and potential
> >>>>> for errors. Have all of the implementation issues that James
> >>>>> brought up been resolved? Remind me why this is better in C than
> >>>>> in an external Python helper. 
> >>>>> 
> >>>> 
> >>>> Its very hacky, we have to close the current transaction (from
> >>>> within the library) so that genhomedircon can connect and get a
> >>>> read lock on the newly created active store and then it modifies
> >>>> the files outside of the module store, non-ideal in almost every
> >>>> way. 
> >>>> 
> >>> 
> >>> Why does it need to get the read lock - why can't it be changed to
> >>> take the sandbox location and work on that directly? Fixing that
> >>> might be better long term as it seems advantageous to allow helper
> >>> programs in general (for separation and least-privilege).
> >>> 
> >> 
> >> Work directly on the module store? The module store is a private
> >> resource of libsemanage, applications should not modify it directly
> >> outside of libsemanage.
> > 
> > genhomedircon is part of libsemanage - it just runs in a
> > separate process. IOW it is just an implementation detail.
> > 
> 
> Not to mention running a python interpreter from a library is pretty
> lame.

Why? It's less lame than doing this string manipulation in C if you ask
me. Not to mention safer - the kind of string manipulation done for this
is perhaps the biggest source of exploitable flaws in software.

[...]

> > 
> > Think about a process to verify untrusted data (like modules)
> > - it would be helpful to allow a separate process to examine
> > that data. Yes things like semodule will have full access but
> > allowing a lower-privileged process to handle some parts is desirable
> > in my opinion. 
> 
> We already have a facility to run external apps that can do that. In
> semanage.conf just do:
> 
> [verify module]
> path=/some/path/to/checker
> [end]
> 
> Which has nothing to do with genhomedircon, genhomedircon is mutating
> the store, we should not be providing a facility to let random programs
> mutate the store arbitrarilly.

My point (that seems to be getting lost) is that genhomedircon is not an
arbitrary program. It's just part of libsemanage. Why shouldn't we allow
separate processes to mutate the store if they are built-in to
libsemanage?

Karl


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [patch 1/3] libsemanage: genhomedircon replacement

[Eamon Walsh]

Karl MacMillan wrote:
> On Thu, 2007-06-21 at 14:25 -0400, Joshua Brindle wrote:
>> Karl MacMillan wrote:
>>> On Thu, 2007-06-21 at 14:09 -0400, Joshua Brindle wrote:
>>>> Karl MacMillan wrote:
>>>>> On Thu, 2007-06-21 at 12:49 -0400, Joshua Brindle wrote:
>>>>>> Karl MacMillan wrote:
>>>>>>> On Tue, 2007-06-19 at 11:09 -0400, Joshua Brindle wrote:
>>>>>>>> Karl MacMillan wrote:
>>>>>>>>> On Fri, 2007-05-25 at 13:06 -0400, Joshua Brindle wrote:
>>>>>>>>>> Karl MacMillan wrote:
>>>>>>>>>>>> If you would like to move the list types out of policyrep and
>>>>>>>>>>>> into trunk, I'll be happy to use it.  Otherwise it is out of
>>>>>>>>>>>> the scope of this patch. 
>>>>>>>>>>>>
>>>>>>>>>>> Please rebase against the policyrep branch - we can then
>>>>>>>>>>> consider merging the list types and this patch to trunk if
>>>>>>>>>>> desired. I will NACK this patch if it contains the
>>>>> additional list types.
>>>>>>>>>> There aren't additional list types because there aren't any in
>>>>>>>>>> trunk. This has nothing to do with policyrep and doesn't break
>>>>>>>>>> ABI compatibility and should be in trunk. I hate this idea of
>>>>>>>>>> pushing everything into policyrep because its going to make it
>>>>>>>>>> that much harder to get good testing done and the source of
>>>>>>>>>> bugs will be harder to track down.
>>>>>>>>>>
>>>>>>>>> Ok.
>>>>>>>>>
>>>>>>>>>> If you are so insistent on using the list types in policyrep
>>>>>>>>>> why not port them to trunk so we can use them?
>>>>>>>>> That option is fine with me (and was one of my suggestions),
>>>>>>>>> though I don't have time to do the port right now. Can you or
>>>>>>>>> Mark send a patch pulling over the iterators and list?
>>>>>>>> I'm going to bring this back up because I think this patch is
>>>>>>>> important to get into upstream as a first step toward generic
>>>>>>>> label generation. 
>>>>>>>>
>>>>>>> Can you tell me a little more about what you are thinking with
>>>>>>> this? 
>>>>>>>
>>>>> ??
>>>>>
>>>> We need labels for various object managers (like policy server)
>>>> generated per user. For example, if you look back at the PoC apache
>>>> metapolicy you'll see some hardcoded labels like user_apache_types_t
>>>> and so on, these need to be generated for each user.
>>>>
>>>>
>>>>>>>> Since we aren't using the policyrep branch anymore and
>>>>>>>> libpolicyrep is going to be in c++ do you still have
>>>>>>>> reservations against this patch? 
>>>>>>>>
>>>>>>> I'm still convinced about the maintenance long term and potential
>>>>>>> for errors. Have all of the implementation issues that James
>>>>>>> brought up been resolved? Remind me why this is better in C than
>>>>>>> in an external Python helper. 
>>>>>>>
>>>>>> Its very hacky, we have to close the current transaction (from
>>>>>> within the library) so that genhomedircon can connect and get a
>>>>>> read lock on the newly created active store and then it modifies
>>>>>> the files outside of the module store, non-ideal in almost every
>>>>>> way. 
>>>>>>
>>>>> Why does it need to get the read lock - why can't it be changed to
>>>>> take the sandbox location and work on that directly? Fixing that
>>>>> might be better long term as it seems advantageous to allow helper
>>>>> programs in general (for separation and least-privilege).
>>>>>
>>>> Work directly on the module store? The module store is a private
>>>> resource of libsemanage, applications should not modify it directly
>>>> outside of libsemanage.
>>> genhomedircon is part of libsemanage - it just runs in a
>>> separate process. IOW it is just an implementation detail.
>>>
>> Not to mention running a python interpreter from a library is pretty
>> lame.
> 
> Why? It's less lame than doing this string manipulation in C if you ask
> me. Not to mention safer - the kind of string manipulation done for this
> is perhaps the biggest source of exploitable flaws in software.

I'm going to do the unthinkable and agree with Josh, I think the 
solution to this is to write correct code, not to give up and use a 
scripting language.  I'm not a fan of the Python dependencies.

> 
> [...]
> 
>>> Think about a process to verify untrusted data (like modules)
>>> - it would be helpful to allow a separate process to examine
>>> that data. Yes things like semodule will have full access but
>>> allowing a lower-privileged process to handle some parts is desirable
>>> in my opinion. 
>> We already have a facility to run external apps that can do that. In
>> semanage.conf just do:
>>
>> [verify module]
>> path=/some/path/to/checker
>> [end]
>>
>> Which has nothing to do with genhomedircon, genhomedircon is mutating
>> the store, we should not be providing a facility to let random programs
>> mutate the store arbitrarilly.
> 
> My point (that seems to be getting lost) is that genhomedircon is not an
> arbitrary program. It's just part of libsemanage. Why shouldn't we allow
> separate processes to mutate the store if they are built-in to
> libsemanage?

Running helpers from a library is IMO a bad idea, because it's not easy 
to completely insulate helper processes from the caller.  Caller could 
get unexpected results from an ill-timed wait(2) call for example, or 
not be expecting strange things in its process tree.


-- 
Eamon Walsh <ewalsh@tycho.nsa.gov>
National Security Agency

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [patch 1/3] libsemanage: genhomedircon replacement

[Daniel J Walsh]

Eamon Walsh wrote:
> Karl MacMillan wrote:
>> On Thu, 2007-06-21 at 14:25 -0400, Joshua Brindle wrote:
>>> Karl MacMillan wrote:
>>>> On Thu, 2007-06-21 at 14:09 -0400, Joshua Brindle wrote:
>>>>> Karl MacMillan wrote:
>>>>>> On Thu, 2007-06-21 at 12:49 -0400, Joshua Brindle wrote:
>>>>>>> Karl MacMillan wrote:
>>>>>>>> On Tue, 2007-06-19 at 11:09 -0400, Joshua Brindle wrote:
>>>>>>>>> Karl MacMillan wrote:
>>>>>>>>>> On Fri, 2007-05-25 at 13:06 -0400, Joshua Brindle wrote:
>>>>>>>>>>> Karl MacMillan wrote:
>>>>>>>>>>>>> If you would like to move the list types out of policyrep and
>>>>>>>>>>>>> into trunk, I'll be happy to use it.  Otherwise it is out of
>>>>>>>>>>>>> the scope of this patch.
>>>>>>>>>>>> Please rebase against the policyrep branch - we can then
>>>>>>>>>>>> consider merging the list types and this patch to trunk if
>>>>>>>>>>>> desired. I will NACK this patch if it contains the
>>>>>> additional list types.
>>>>>>>>>>> There aren't additional list types because there aren't any in
>>>>>>>>>>> trunk. This has nothing to do with policyrep and doesn't break
>>>>>>>>>>> ABI compatibility and should be in trunk. I hate this idea of
>>>>>>>>>>> pushing everything into policyrep because its going to make it
>>>>>>>>>>> that much harder to get good testing done and the source of
>>>>>>>>>>> bugs will be harder to track down.
>>>>>>>>>>>
>>>>>>>>>> Ok.
>>>>>>>>>>
>>>>>>>>>>> If you are so insistent on using the list types in policyrep
>>>>>>>>>>> why not port them to trunk so we can use them?
>>>>>>>>>> That option is fine with me (and was one of my suggestions),
>>>>>>>>>> though I don't have time to do the port right now. Can you or
>>>>>>>>>> Mark send a patch pulling over the iterators and list?
>>>>>>>>> I'm going to bring this back up because I think this patch is
>>>>>>>>> important to get into upstream as a first step toward generic
>>>>>>>>> label generation.
>>>>>>>> Can you tell me a little more about what you are thinking with
>>>>>>>> this?
>>>>>> ??
>>>>>>
>>>>> We need labels for various object managers (like policy server)
>>>>> generated per user. For example, if you look back at the PoC apache
>>>>> metapolicy you'll see some hardcoded labels like user_apache_types_t
>>>>> and so on, these need to be generated for each user.
>>>>>
>>>>>
>>>>>>>>> Since we aren't using the policyrep branch anymore and
>>>>>>>>> libpolicyrep is going to be in c++ do you still have
>>>>>>>>> reservations against this patch?
>>>>>>>> I'm still convinced about the maintenance long term and potential
>>>>>>>> for errors. Have all of the implementation issues that James
>>>>>>>> brought up been resolved? Remind me why this is better in C than
>>>>>>>> in an external Python helper.
>>>>>>> Its very hacky, we have to close the current transaction (from
>>>>>>> within the library) so that genhomedircon can connect and get a
>>>>>>> read lock on the newly created active store and then it modifies
>>>>>>> the files outside of the module store, non-ideal in almost every
>>>>>>> way.
>>>>>> Why does it need to get the read lock - why can't it be changed to
>>>>>> take the sandbox location and work on that directly? Fixing that
>>>>>> might be better long term as it seems advantageous to allow helper
>>>>>> programs in general (for separation and least-privilege).
>>>>>>
>>>>> Work directly on the module store? The module store is a private
>>>>> resource of libsemanage, applications should not modify it directly
>>>>> outside of libsemanage.
>>>> genhomedircon is part of libsemanage - it just runs in a
>>>> separate process. IOW it is just an implementation detail.
>>>>
>>> Not to mention running a python interpreter from a library is pretty
>>> lame.
>>
>> Why? It's less lame than doing this string manipulation in C if you ask
>> me. Not to mention safer - the kind of string manipulation done for this
>> is perhaps the biggest source of exploitable flaws in software.
>
> I'm going to do the unthinkable and agree with Josh, I think the 
> solution to this is to write correct code, not to give up and use a 
> scripting language.  I'm not a fan of the Python dependencies.
>
>>
>> [...]
>>
>>>> Think about a process to verify untrusted data (like modules)
>>>> - it would be helpful to allow a separate process to examine
>>>> that data. Yes things like semodule will have full access but
>>>> allowing a lower-privileged process to handle some parts is desirable
>>>> in my opinion. 
>>> We already have a facility to run external apps that can do that. In
>>> semanage.conf just do:
>>>
>>> [verify module]
>>> path=/some/path/to/checker
>>> [end]
>>>
>>> Which has nothing to do with genhomedircon, genhomedircon is mutating
>>> the store, we should not be providing a facility to let random programs
>>> mutate the store arbitrarilly.
>>
>> My point (that seems to be getting lost) is that genhomedircon is not an
>> arbitrary program. It's just part of libsemanage. Why shouldn't we allow
>> separate processes to mutate the store if they are built-in to
>> libsemanage?
>
> Running helpers from a library is IMO a bad idea, because it's not 
> easy to completely insulate helper processes from the caller.  Caller 
> could get unexpected results from an ill-timed wait(2) call for 
> example, or not be expecting strange things in its process tree.
>
>
Just food for thought.

Change genhomedircon to output to stdout.  Now it does not need privs to 
manipulate the file store.  libsemanage can read its output and do the 
manipulation.

My concern about converting genhomedircon to C is the experimentation 
with the script will get much more difficult.  For example a couple of 
things that could be tried are figuring out if a machine has automounted 
home directories (local or remote) and generating the correct context. 
Handling the situation where you can not get the list of all potential 
users.  Rewriting this tool in C not only increases the chance of coding 
problems, it also eliminates many developers who could potentially work 
with it.

Currently we treat via policy genhomedircon, semanage, setsebool, 
semodule with the same semanage_exec_t.  I want to break these tools up 
via least privs, especially setsebool.  To allow specific administrators 
to only set certain booleans.  The way the library currently works makes 
this difficult.

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [patch 1/3] libsemanage: genhomedircon replacement

[Karl MacMillan]

On Thu, 2007-06-21 at 16:54 -0400, Eamon Walsh wrote:
> Karl MacMillan wrote:
> > On Thu, 2007-06-21 at 14:25 -0400, Joshua Brindle wrote:
> >> Karl MacMillan wrote:
> >>> On Thu, 2007-06-21 at 14:09 -0400, Joshua Brindle wrote:

[...]

> >> Not to mention running a python interpreter from a library is pretty
> >> lame.
> > 
> > Why? It's less lame than doing this string manipulation in C if you ask
> > me. Not to mention safer - the kind of string manipulation done for this
> > is perhaps the biggest source of exploitable flaws in software.
> 
> I'm going to do the unthinkable and agree with Josh,

Now, now, I agree with Josh all the time.

>  I think the 
> solution to this is to write correct code, not to give up and use a 
> scripting language.

Because writing correct code has worked so well for all of those other
projects with exploitable flaws . . .

>   I'm not a fan of the Python dependencies.
> 

Why?

> > 
> > [...]
> > 
> >>> Think about a process to verify untrusted data (like modules)
> >>> - it would be helpful to allow a separate process to examine
> >>> that data. Yes things like semodule will have full access but
> >>> allowing a lower-privileged process to handle some parts is desirable
> >>> in my opinion. 
> >> We already have a facility to run external apps that can do that. In
> >> semanage.conf just do:
> >>
> >> [verify module]
> >> path=/some/path/to/checker
> >> [end]
> >>
> >> Which has nothing to do with genhomedircon, genhomedircon is mutating
> >> the store, we should not be providing a facility to let random programs
> >> mutate the store arbitrarilly.
> > 
> > My point (that seems to be getting lost) is that genhomedircon is not an
> > arbitrary program. It's just part of libsemanage. Why shouldn't we allow
> > separate processes to mutate the store if they are built-in to
> > libsemanage?
> 
> Running helpers from a library is IMO a bad idea, because it's not easy 
> to completely insulate helper processes from the caller.  Caller could 
> get unexpected results from an ill-timed wait(2) call for example, or 
> not be expecting strange things in its process tree.
> 

I'm not convinced by this. First, we've been doing this for a long time
and haven't had a single problem. Second, libsemanage is not a typical
library (like, say, libm). Callers likely need to be fairly familiar
with how it works and use it carefully.

Other than being in-process, what are the other advantageous of writing
this in C (I've heard none). If it is just making it in-process why
don't we just embed the python interpreter :)

Karl


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: [patch 1/3] libsemanage: genhomedircon replacement

[Joshua Brindle]

Karl MacMillan wrote:
> On Thu, 2007-06-21 at 16:54 -0400, Eamon Walsh wrote:
>> Karl MacMillan wrote:
>>> On Thu, 2007-06-21 at 14:25 -0400, Joshua Brindle wrote:
>>>> Karl MacMillan wrote:
>>>>> On Thu, 2007-06-21 at 14:09 -0400, Joshua Brindle wrote:

> 
> I'm not convinced by this. First, we've been doing this for a
> long time and haven't had a single problem. Second,
> libsemanage is not a typical library (like, say, libm).
> Callers likely need to be fairly familiar with how it works and use
> it carefully. 
> 
> Other than being in-process, what are the other advantageous
> of writing this in C (I've heard none). If it is just making
> it in-process why don't we just embed the python interpreter :)
>

Wow, talk about hacky... Anyway, I've already told you the advantage.
We'll have to get rid of genhomedircon as it currently exists (as an
independent user of libsemanage itself) and completely rewrite it to
operate on the sandbox to get equivalent functionality. The C rewrite is
already complete and is consistent with the way the rest of libsemanage
works (doing work in the sandbox in the library). Why should
genhomedircon be different than any of the other activities libsemanage
does on the files in the sandbox (including parsing, rewriting, etc)?

IIRC running genhomedircon out of the library was always considered
temporary until we got around to rewriting it to be a proper part of the
library, I'm not sure why you are objecting so strongly, this is the
natural progression. This also makes it much easier to use modular
policy in embedded deployments since they often do not have python. With
libpolicyrep being in c++ and libsemanage being completely in C one
could use policy modules without python altogether (and even reimplement
parts of semanage in C if that functionality were desired)


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: [patch 1/3] libsemanage: genhomedircon replacement

[Karl MacMillan]

On Fri, 2007-06-22 at 11:31 -0400, Joshua Brindle wrote:
> Karl MacMillan wrote:
> > On Thu, 2007-06-21 at 16:54 -0400, Eamon Walsh wrote:
> >> Karl MacMillan wrote:
> >>> On Thu, 2007-06-21 at 14:25 -0400, Joshua Brindle wrote:
> >>>> Karl MacMillan wrote:
> >>>>> On Thu, 2007-06-21 at 14:09 -0400, Joshua Brindle wrote:
> 
> > 
> > I'm not convinced by this. First, we've been doing this for a
> > long time and haven't had a single problem. Second,
> > libsemanage is not a typical library (like, say, libm).
> > Callers likely need to be fairly familiar with how it works and use
> > it carefully. 
> > 
> > Other than being in-process, what are the other advantageous
> > of writing this in C (I've heard none). If it is just making
> > it in-process why don't we just embed the python interpreter :)
> >
> 
> Wow, talk about hacky... Anyway, I've already told you the advantage.

Err - you mentioned generating labels for object managers (could be done
in genhomedircon) and the locking issues that I've addressed.

> We'll have to get rid of genhomedircon as it currently exists (as an
> independent user of libsemanage itself) and completely rewrite it to
> operate on the sandbox to get equivalent functionality.

That is a bit of an overstatement - I don't think the changes would be
hard.

>  The C rewrite is
> already complete and is consistent with the way the rest of libsemanage
> works (doing work in the sandbox in the library). Why should
> genhomedircon be different than any of the other activities libsemanage
> does on the files in the sandbox (including parsing, rewriting, etc)?
> 

Because this type of string manipulation is so painful in C. Can you
post a more recent patch - I just looked and couldn't find a new patch
that addressed the comments in the archives. The original version had
some fairly significant flaws, including potentially security relevant
flaws (which doesn't help the "let's just implement it correctly"
argument).

> IIRC running genhomedircon out of the library was always considered
> temporary until we got around to rewriting it to be a proper part of the
> library, I'm not sure why you are objecting so strongly, this is the
> natural progression. This also makes it much easier to use modular
> policy in embedded deployments since they often do not have python. With
> libpolicyrep being in c++ and libsemanage being completely in C one
> could use policy modules without python altogether (and even reimplement
> parts of semanage in C if that functionality were desired)

Removing the dependency is fairly nice - but I'm not convinced that
embedded environments will use modular policy.

I'm not totally against this - it's just that the C version is always
going to be ugly.

Karl


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [patch 1/3] libsemanage: genhomedircon replacement

[Eamon Walsh]

Karl MacMillan wrote:
> On Thu, 2007-06-21 at 16:54 -0400, Eamon Walsh wrote:
> 
>>   I'm not a fan of the Python dependencies.
>>
> 
> Why?

Here's a nice example of RPM hell, courtesy of our Python dependency.  I 
got this earlier in the year on one of my machines.


# yum -y upgrade
--> Running transaction check
--> Processing Dependency: gnutls-devel for package: libsoup-devel
--> Processing Dependency: python(abi) = 2.4 for package: audit-libs-python
--> Restarting Dependency Resolution with new changes.
--> Populating transaction set with selected packages. Please wait.
---> Package gnutls-devel.i386 0:1.4.5-1 set to be updated
--> Running transaction check
--> Processing Dependency: python(abi) = 2.4 for package: audit-libs-python
--> Finished Dependency Resolution
Error: Missing Dependency: python(abi) = 2.4 is needed by package 
audit-libs-python


-- 
Eamon Walsh <ewalsh@tycho.nsa.gov>
National Security Agency

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [patch 1/3] libsemanage: genhomedircon replacement

[Karl MacMillan]

On Fri, 2007-06-22 at 12:58 -0400, Eamon Walsh wrote:
> Karl MacMillan wrote:
> > On Thu, 2007-06-21 at 16:54 -0400, Eamon Walsh wrote:
> > 
> >>   I'm not a fan of the Python dependencies.
> >>
> > 
> > Why?
> 
> Here's a nice example of RPM hell, courtesy of our Python dependency.  I 
> got this earlier in the year on one of my machines.
> 
> 
> # yum -y upgrade
> --> Running transaction check
> --> Processing Dependency: gnutls-devel for package: libsoup-devel
> --> Processing Dependency: python(abi) = 2.4 for package: audit-libs-python
> --> Restarting Dependency Resolution with new changes.
> --> Populating transaction set with selected packages. Please wait.
> ---> Package gnutls-devel.i386 0:1.4.5-1 set to be updated
> --> Running transaction check
> --> Processing Dependency: python(abi) = 2.4 for package: audit-libs-python
> --> Finished Dependency Resolution
> Error: Missing Dependency: python(abi) = 2.4 is needed by package 
> audit-libs-python
> 

Rawhide or a release? Was this during the move to 2.5?

Larger issue, though, is that any dependency could cause the same
problem. I'm not convinced that what was likely a packaging error or yum
error should prevent us from using the best tools for the job.

Again: I'm not totally against this. I'm just very concerned about the
potential for problems in this code and the initial implementation
confirmed all of those concerns. Is it possible to get this code correct
in C? Sure. Is it likely for it to be correct initially and stay that
way is the question.

Can I suggest a middle ground? Implement in C (or C++) but use a string
library.

Karl



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [patch 1/3] libsemanage: genhomedircon replacement

[Eamon Walsh]

Karl MacMillan wrote:
> On Fri, 2007-06-22 at 12:58 -0400, Eamon Walsh wrote:
>> Karl MacMillan wrote:
>>> On Thu, 2007-06-21 at 16:54 -0400, Eamon Walsh wrote:
>>>
>>>>   I'm not a fan of the Python dependencies.
>>>>
>>> Why?
>> Here's a nice example of RPM hell, courtesy of our Python dependency.  I 
>> got this earlier in the year on one of my machines.
>>
>>
>> # yum -y upgrade
>> --> Running transaction check
>> --> Processing Dependency: gnutls-devel for package: libsoup-devel
>> --> Processing Dependency: python(abi) = 2.4 for package: audit-libs-python
>> --> Restarting Dependency Resolution with new changes.
>> --> Populating transaction set with selected packages. Please wait.
>> ---> Package gnutls-devel.i386 0:1.4.5-1 set to be updated
>> --> Running transaction check
>> --> Processing Dependency: python(abi) = 2.4 for package: audit-libs-python
>> --> Finished Dependency Resolution
>> Error: Missing Dependency: python(abi) = 2.4 is needed by package 
>> audit-libs-python
>>
> 
> Rawhide or a release? Was this during the move to 2.5?

It was upgrading across the 2.4/2.5 switch, not rawhide as I recall.  To 
answer James, this was just an example of a problem I ran into; I don't 
have any specific problems with the bindings.

> 
> Larger issue, though, is that any dependency could cause the same
> problem. I'm not convinced that what was likely a packaging error or yum
> error should prevent us from using the best tools for the job.
> 
> Again: I'm not totally against this. I'm just very concerned about the
> potential for problems in this code and the initial implementation
> confirmed all of those concerns. Is it possible to get this code correct
> in C? Sure. Is it likely for it to be correct initially and stay that
> way is the question.
> 
> Can I suggest a middle ground? Implement in C (or C++) but use a string
> library.

A library would be great, I'm still depressed about glib's 
abort-on-malloc making it unusable.  ustr was mentioned earlier as a 
possible library that could be used.


-- 
Eamon Walsh <ewalsh@tycho.nsa.gov>
National Security Agency

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [patch 1/3] libsemanage: genhomedircon replacement

[Joshua Brindle]

Eamon Walsh wrote:
> Karl MacMillan wrote:
>> On Fri, 2007-06-22 at 12:58 -0400, Eamon Walsh wrote:
>>> Karl MacMillan wrote:
>>>> On Thu, 2007-06-21 at 16:54 -0400, Eamon Walsh wrote:
>>>>
>>>>>   I'm not a fan of the Python dependencies.
>>>>>
>>>> Why?
>>> Here's a nice example of RPM hell, courtesy of our Python 
>>> dependency.  I got this earlier in the year on one of my machines.
>>>
>>>
>>> # yum -y upgrade
>>> --> Running transaction check
>>> --> Processing Dependency: gnutls-devel for package: libsoup-devel
>>> --> Processing Dependency: python(abi) = 2.4 for package: 
>>> audit-libs-python
>>> --> Restarting Dependency Resolution with new changes.
>>> --> Populating transaction set with selected packages. Please wait.
>>> ---> Package gnutls-devel.i386 0:1.4.5-1 set to be updated
>>> --> Running transaction check
>>> --> Processing Dependency: python(abi) = 2.4 for package: 
>>> audit-libs-python
>>> --> Finished Dependency Resolution
>>> Error: Missing Dependency: python(abi) = 2.4 is needed by package 
>>> audit-libs-python
>>>
>>
>> Rawhide or a release? Was this during the move to 2.5?
> 
> It was upgrading across the 2.4/2.5 switch, not rawhide as I recall.  To 
> answer James, this was just an example of a problem I ran into; I don't 
> have any specific problems with the bindings.
> 
>>
>> Larger issue, though, is that any dependency could cause the same
>> problem. I'm not convinced that what was likely a packaging error or yum
>> error should prevent us from using the best tools for the job.
>>
>> Again: I'm not totally against this. I'm just very concerned about the
>> potential for problems in this code and the initial implementation
>> confirmed all of those concerns. Is it possible to get this code correct
>> in C? Sure. Is it likely for it to be correct initially and stay that
>> way is the question.
>>
>> Can I suggest a middle ground? Implement in C (or C++) but use a string
>> library.
> 
> A library would be great, I'm still depressed about glib's 
> abort-on-malloc making it unusable.  ustr was mentioned earlier as a 
> possible library that could be used.
> 
> 

Unfortunately ustr isn't in yum so we'd have to pull code into the lib 
itself, which I'd prefer not to. Additionally ustr's documentation is a 
bit lacking: http://www.and.org/ustr/functions . Stuff like "This 
function does nothing." in the docs is a bit disconcerting as well.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [patch 1/3] libsemanage: genhomedircon replacement

[Karl MacMillan]

On Mon, 2007-07-02 at 10:00 -0400, Joshua Brindle wrote:
> Eamon Walsh wrote:
> > Karl MacMillan wrote:
> >> On Fri, 2007-06-22 at 12:58 -0400, Eamon Walsh wrote:
> >>> Karl MacMillan wrote:
> >>>> On Thu, 2007-06-21 at 16:54 -0400, Eamon Walsh wrote:
> >>>>
> >>>>>   I'm not a fan of the Python dependencies.
> >>>>>
> >>>> Why?
> >>> Here's a nice example of RPM hell, courtesy of our Python 
> >>> dependency.  I got this earlier in the year on one of my machines.
> >>>
> >>>
> >>> # yum -y upgrade
> >>> --> Running transaction check
> >>> --> Processing Dependency: gnutls-devel for package: libsoup-devel
> >>> --> Processing Dependency: python(abi) = 2.4 for package: 
> >>> audit-libs-python
> >>> --> Restarting Dependency Resolution with new changes.
> >>> --> Populating transaction set with selected packages. Please wait.
> >>> ---> Package gnutls-devel.i386 0:1.4.5-1 set to be updated
> >>> --> Running transaction check
> >>> --> Processing Dependency: python(abi) = 2.4 for package: 
> >>> audit-libs-python
> >>> --> Finished Dependency Resolution
> >>> Error: Missing Dependency: python(abi) = 2.4 is needed by package 
> >>> audit-libs-python
> >>>
> >>
> >> Rawhide or a release? Was this during the move to 2.5?
> > 
> > It was upgrading across the 2.4/2.5 switch, not rawhide as I recall.  To 
> > answer James, this was just an example of a problem I ran into; I don't 
> > have any specific problems with the bindings.
> > 
> >>
> >> Larger issue, though, is that any dependency could cause the same
> >> problem. I'm not convinced that what was likely a packaging error or yum
> >> error should prevent us from using the best tools for the job.
> >>
> >> Again: I'm not totally against this. I'm just very concerned about the
> >> potential for problems in this code and the initial implementation
> >> confirmed all of those concerns. Is it possible to get this code correct
> >> in C? Sure. Is it likely for it to be correct initially and stay that
> >> way is the question.
> >>
> >> Can I suggest a middle ground? Implement in C (or C++) but use a string
> >> library.
> > 
> > A library would be great, I'm still depressed about glib's 
> > abort-on-malloc making it unusable.  ustr was mentioned earlier as a 
> > possible library that could be used.
> > 
> > 
> 
> Unfortunately ustr isn't in yum so we'd have to pull code into the lib 
> itself, which I'd prefer not to.

Ustr is intended to be pulled into projects - that's why it is a single
file.

>  Additionally ustr's documentation is a 
> bit lacking: http://www.and.org/ustr/functions . Stuff like "This 
> function does nothing." in the docs is a bit disconcerting as well.
> 

I'm certain James can answer any questions.

More to the point - what do you think of using some string library?

Karl


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: [patch 1/3] libsemanage: genhomedircon replacement

[Joshua Brindle]

Karl MacMillan wrote:
> On Mon, 2007-07-02 at 10:00 -0400, Joshua Brindle wrote:

> 
> I'm certain James can answer any questions.
> 
> More to the point - what do you think of using some string library?
> 

I'm not at all adverse to the idea, I even suggested it quite a while
back and was denied due to our anti-dependency mindset at the time.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [patch 1/3] libsemanage: genhomedircon replacement

[Joshua Brindle]

Karl MacMillan wrote:
> On Mon, 2007-07-02 at 10:00 -0400, Joshua Brindle wrote:
>> Eamon Walsh wrote:
>>> Karl MacMillan wrote:
>>>> On Fri, 2007-06-22 at 12:58 -0400, Eamon Walsh wrote:
>>>>> Karl MacMillan wrote:
>>>>>> On Thu, 2007-06-21 at 16:54 -0400, Eamon Walsh wrote:
>>>>>>
>>>>>>>   I'm not a fan of the Python dependencies.
>>>>>>>
>>>>>> Why?
>>>>> Here's a nice example of RPM hell, courtesy of our Python 
>>>>> dependency.  I got this earlier in the year on one of my machines.
>>>>>
>>>>>
>>>>> # yum -y upgrade
>>>>> --> Running transaction check
>>>>> --> Processing Dependency: gnutls-devel for package: libsoup-devel
>>>>> --> Processing Dependency: python(abi) = 2.4 for package: 
>>>>> audit-libs-python
>>>>> --> Restarting Dependency Resolution with new changes.
>>>>> --> Populating transaction set with selected packages. Please wait.
>>>>> ---> Package gnutls-devel.i386 0:1.4.5-1 set to be updated
>>>>> --> Running transaction check
>>>>> --> Processing Dependency: python(abi) = 2.4 for package: 
>>>>> audit-libs-python
>>>>> --> Finished Dependency Resolution
>>>>> Error: Missing Dependency: python(abi) = 2.4 is needed by package 
>>>>> audit-libs-python
>>>>>
>>>> Rawhide or a release? Was this during the move to 2.5?
>>> It was upgrading across the 2.4/2.5 switch, not rawhide as I recall.  To 
>>> answer James, this was just an example of a problem I ran into; I don't 
>>> have any specific problems with the bindings.
>>>
>>>> Larger issue, though, is that any dependency could cause the same
>>>> problem. I'm not convinced that what was likely a packaging error or yum
>>>> error should prevent us from using the best tools for the job.
>>>>
>>>> Again: I'm not totally against this. I'm just very concerned about the
>>>> potential for problems in this code and the initial implementation
>>>> confirmed all of those concerns. Is it possible to get this code correct
>>>> in C? Sure. Is it likely for it to be correct initially and stay that
>>>> way is the question.
>>>>
>>>> Can I suggest a middle ground? Implement in C (or C++) but use a string
>>>> library.
>>> A library would be great, I'm still depressed about glib's 
>>> abort-on-malloc making it unusable.  ustr was mentioned earlier as a 
>>> possible library that could be used.
>>>
>>>
>> Unfortunately ustr isn't in yum so we'd have to pull code into the lib 
>> itself, which I'd prefer not to.
> 
> Ustr is intended to be pulled into projects - that's why it is a single
> file.
> 

eh?

[root@scarecrow ustr-0.99.3]# ls *.c | wc -l
23

this does not include tests or examples.

>>  Additionally ustr's documentation is a 
>> bit lacking: http://www.and.org/ustr/functions . Stuff like "This 
>> function does nothing." in the docs is a bit disconcerting as well.
>>
> 
> I'm certain James can answer any questions.
> 
> More to the point - what do you think of using some string library?
> 

We are deciding if ustr is the right answer right now, and will report 
our findings later.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [patch 1/3] libsemanage: genhomedircon replacement

[James Antill]

[-- Attachment #1: Type: text/plain, Size: 1782 bytes --]

On Mon, 2007-07-02 at 17:26 -0400, Joshua Brindle wrote:
> Karl MacMillan wrote:

> > Ustr is intended to be pulled into projects - that's why it is a single
> > file.
> > 
> 
> eh?
> 
> [root@scarecrow ustr-0.99.3]# ls *.c | wc -l
> 23
> 
> this does not include tests or examples.

 Karl was "consulted" on very earl versions, at which point it was
entirely contained within a single sub 1,000[1] line .h file. You can
still install the developer rpm and use:

 ustr-import main

...which will get you the smallest local copy possible (basically just
the ustr_add, ustr_dup, ustr_del and accessor functions).
 For libselinux usage though, I'd assume you can go for linking to the
shared lib. when[2] that's in the main Fedora repo?

> >>  Additionally ustr's documentation is a 
> >> bit lacking: http://www.and.org/ustr/functions . Stuff like "This 
> >> function does nothing." in the docs is a bit disconcerting as well.
> > 
> > I'm certain James can answer any questions.
> > 
> > More to the point - what do you think of using some string library?
> 
> We are deciding if ustr is the right answer right now, and will report 
> our findings later.

 Well, as Karl said I'd be happy to provide any answers to make the
choice easier for you. I can also be pursuaded to do some code to help
your choice, if you have something in mind?


[1] It's bigger now, but at least it doesn't send email yet :).

[2] I'm looking to do a 1.0, with "significant"[3] documentation and a
stable API within the next week or so.

[3] Ie. maybe not every function, but enough that a normal person could
work out the rest. Also I make no promises about my skill to make you
understand everythign I say :).

-- 
James Antill <jantill@redhat.com>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Can someone please assist me with selinux issue

[David Cottle]

[-- Attachment #1: Type: text/plain, Size: 2157 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

I got a ftp session from a IP camera sending images every 1 minute.

I keep getting these AVC messages in /var/logs/messages:

Jul  1 04:43:40 server kernel: audit(1183229020.232:8256): avc:
denied  { link } for  pid=2043 comm="in.proftpd"
scontext=system_u:system_r:ftpd_t:s0
tcontext=system_u:system_r:ftpd_t:s0 tclass=key
Jul  1 04:44:40 server kernel: audit(1183229080.245:8257): avc:
denied  { link } for  pid=2061 comm="in.proftpd"
scontext=system_u:system_r:ftpd_t:s0
tcontext=system_u:system_r:ftpd_t:s0 tclass=key
Jul  1 04:45:40 server kernel: audit(1183229140.367:8258): avc:
denied  { link } for  pid=2259 comm="in.proftpd"
scontext=system_u:system_r:ftpd_t:s0
tcontext=system_u:system_r:crond_t:s0-s0:c0.c1023 tclass=key
Jul  1 04:46:40 server kernel: audit(1183229200.238:8259): avc:
denied  { link } for  pid=2267 comm="in.proftpd"
scontext=system_u:system_r:ftpd_t:s0
tcontext=system_u:system_r:crond_t:s0-s0:c0.c1023 tclass=key

Every time there is a transfer.  So at 1 minute intervals there are
too many.  Also I want to add more webcams so no doubt its going to
get worse.

However I read and created a policy:

grep proftpd /var/log/messages | audit2allow -M proftpd
selinux -i proftpd.pp


However the above I STILL get the annoying AVC denied messages.

Can someone please explain and tell me how can I update and get rid of
the denied messages?

This is the proftpd.te rule it made:

module proftpd 1.0;

require {
    type ftpd_t;
    type crond_t;
    type httpd_suexec_t;
    class capability dac_override;
    class key { write search };
}

#============= ftpd_t ==============
allow ftpd_t crond_t:key search;
allow ftpd_t httpd_suexec_t:key search;
allow ftpd_t self:capability dac_override;
allow ftpd_t self:key { write search };


But I see crond, httpd and ftpd all there but this rule does nothing :(

I also

Thanks!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFGii/ii1lOcz5YUMgRAn/rAKCnY3qmgNoYKd6t77OTHc834Yx6NQCgsAAF
lwnIP6dBcXqqKfyoYg90yoI=
=x4nB
-----END PGP SIGNATURE-----


[-- Attachment #2: webmaster.vcf --]
[-- Type: text/x-vcard, Size: 120 bytes --]

begin:vcard
fn:David Cottle
n:Cottle;David
email;internet:webmaster@aus-city.com
title:Webmaster
version:2.1
end:vcard

Re: Can someone please assist me with selinux issue

[Stephen Smalley]

On Tue, 2007-07-03 at 21:15 +1000, David Cottle wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi,
> 
> I got a ftp session from a IP camera sending images every 1 minute.
> 
> I keep getting these AVC messages in /var/logs/messages:
> 
> Jul  1 04:43:40 server kernel: audit(1183229020.232:8256): avc:
> denied  { link } for  pid=2043 comm="in.proftpd"
> scontext=system_u:system_r:ftpd_t:s0
> tcontext=system_u:system_r:ftpd_t:s0 tclass=key
> Jul  1 04:44:40 server kernel: audit(1183229080.245:8257): avc:
> denied  { link } for  pid=2061 comm="in.proftpd"
> scontext=system_u:system_r:ftpd_t:s0
> tcontext=system_u:system_r:ftpd_t:s0 tclass=key
> Jul  1 04:45:40 server kernel: audit(1183229140.367:8258): avc:
> denied  { link } for  pid=2259 comm="in.proftpd"
> scontext=system_u:system_r:ftpd_t:s0
> tcontext=system_u:system_r:crond_t:s0-s0:c0.c1023 tclass=key
> Jul  1 04:46:40 server kernel: audit(1183229200.238:8259): avc:
> denied  { link } for  pid=2267 comm="in.proftpd"
> scontext=system_u:system_r:ftpd_t:s0
> tcontext=system_u:system_r:crond_t:s0-s0:c0.c1023 tclass=key
> 
> Every time there is a transfer.  So at 1 minute intervals there are
> too many.  Also I want to add more webcams so no doubt its going to
> get worse.
> 
> However I read and created a policy:
> 
> grep proftpd /var/log/messages | audit2allow -M proftpd
> selinux -i proftpd.pp
> 
> 
> However the above I STILL get the annoying AVC denied messages.
> 
> Can someone please explain and tell me how can I update and get rid of
> the denied messages?
> 
> This is the proftpd.te rule it made:
> 
> module proftpd 1.0;
> 
> require {
>     type ftpd_t;
>     type crond_t;
>     type httpd_suexec_t;
>     class capability dac_override;
>     class key { write search };
> }
> 
> #============= ftpd_t ==============
> allow ftpd_t crond_t:key search;
> allow ftpd_t httpd_suexec_t:key search;
> allow ftpd_t self:capability dac_override;
> allow ftpd_t self:key { write search };

You don't seem to be allowing "link" permission above, which is what was
being denied by the audit messages you posted.

> But I see crond, httpd and ftpd all there but this rule does nothing :(

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Can someone please assist me with selinux issue

[David Cottle]

[-- Attachment #1: Type: text/plain, Size: 2663 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thanks for the reply Stephen.  How do I enable the 'link' permission
as you described?

Cheers!

David

Stephen Smalley wrote:
> On Tue, 2007-07-03 at 21:15 +1000, David Cottle wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Hi,
>>
>> I got a ftp session from a IP camera sending images every 1 minute.
>>
>> I keep getting these AVC messages in /var/logs/messages:
>>
>> Jul  1 04:43:40 server kernel: audit(1183229020.232:8256): avc:
>> denied  { link } for  pid=2043 comm="in.proftpd"
>> scontext=system_u:system_r:ftpd_t:s0
>> tcontext=system_u:system_r:ftpd_t:s0 tclass=key
>> Jul  1 04:44:40 server kernel: audit(1183229080.245:8257): avc:
>> denied  { link } for  pid=2061 comm="in.proftpd"
>> scontext=system_u:system_r:ftpd_t:s0
>> tcontext=system_u:system_r:ftpd_t:s0 tclass=key
>> Jul  1 04:45:40 server kernel: audit(1183229140.367:8258): avc:
>> denied  { link } for  pid=2259 comm="in.proftpd"
>> scontext=system_u:system_r:ftpd_t:s0
>> tcontext=system_u:system_r:crond_t:s0-s0:c0.c1023 tclass=key
>> Jul  1 04:46:40 server kernel: audit(1183229200.238:8259): avc:
>> denied  { link } for  pid=2267 comm="in.proftpd"
>> scontext=system_u:system_r:ftpd_t:s0
>> tcontext=system_u:system_r:crond_t:s0-s0:c0.c1023 tclass=key
>>
>> Every time there is a transfer.  So at 1 minute intervals there are
>> too many.  Also I want to add more webcams so no doubt its going to
>> get worse.
>>
>> However I read and created a policy:
>>
>> grep proftpd /var/log/messages | audit2allow -M proftpd
>> selinux -i proftpd.pp
>>
>>
>> However the above I STILL get the annoying AVC denied messages.
>>
>> Can someone please explain and tell me how can I update and get rid of
>> the denied messages?
>>
>> This is the proftpd.te rule it made:
>>
>> module proftpd 1.0;
>>
>> require {
>>     type ftpd_t;
>>     type crond_t;
>>     type httpd_suexec_t;
>>     class capability dac_override;
>>     class key { write search };
>> }
>>
>> #============= ftpd_t ==============
>> allow ftpd_t crond_t:key search;
>> allow ftpd_t httpd_suexec_t:key search;
>> allow ftpd_t self:capability dac_override;
>> allow ftpd_t self:key { write search };
>
> You don't seem to be allowing "link" permission above, which is what was
> being denied by the audit messages you posted.
>
>> But I see crond, httpd and ftpd all there but this rule does nothing :(
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFGjC2Ui1lOcz5YUMgRAuctAJ9ud3yxGylHozKDgI3eIf3U7p1vTgCgpaem
3taj9Wm+FbUKTtzw1w5ksLs=
=/2aU
-----END PGP SIGNATURE-----


[-- Attachment #2: webmaster.vcf --]
[-- Type: text/x-vcard, Size: 120 bytes --]

begin:vcard
fn:David Cottle
n:Cottle;David
email;internet:webmaster@aus-city.com
title:Webmaster
version:2.1
end:vcard

Re: Can someone please assist me with selinux issue

[Stephen Smalley]

On Thu, 2007-07-05 at 09:30 +1000, David Cottle wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Thanks for the reply Stephen.  How do I enable the 'link' permission
> as you described?

In the same way you allowed the others, i.e. add link to the list of
permissions in class key in the require block and in the allow rule.

> 
> Cheers!
> 
> David
> 
> Stephen Smalley wrote:
> > On Tue, 2007-07-03 at 21:15 +1000, David Cottle wrote:
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> Hi,
> >>
> >> I got a ftp session from a IP camera sending images every 1 minute.
> >>
> >> I keep getting these AVC messages in /var/logs/messages:
> >>
> >> Jul  1 04:43:40 server kernel: audit(1183229020.232:8256): avc:
> >> denied  { link } for  pid=2043 comm="in.proftpd"
> >> scontext=system_u:system_r:ftpd_t:s0
> >> tcontext=system_u:system_r:ftpd_t:s0 tclass=key
> >> Jul  1 04:44:40 server kernel: audit(1183229080.245:8257): avc:
> >> denied  { link } for  pid=2061 comm="in.proftpd"
> >> scontext=system_u:system_r:ftpd_t:s0
> >> tcontext=system_u:system_r:ftpd_t:s0 tclass=key
> >> Jul  1 04:45:40 server kernel: audit(1183229140.367:8258): avc:
> >> denied  { link } for  pid=2259 comm="in.proftpd"
> >> scontext=system_u:system_r:ftpd_t:s0
> >> tcontext=system_u:system_r:crond_t:s0-s0:c0.c1023 tclass=key
> >> Jul  1 04:46:40 server kernel: audit(1183229200.238:8259): avc:
> >> denied  { link } for  pid=2267 comm="in.proftpd"
> >> scontext=system_u:system_r:ftpd_t:s0
> >> tcontext=system_u:system_r:crond_t:s0-s0:c0.c1023 tclass=key
> >>
> >> Every time there is a transfer.  So at 1 minute intervals there are
> >> too many.  Also I want to add more webcams so no doubt its going to
> >> get worse.
> >>
> >> However I read and created a policy:
> >>
> >> grep proftpd /var/log/messages | audit2allow -M proftpd
> >> selinux -i proftpd.pp
> >>
> >>
> >> However the above I STILL get the annoying AVC denied messages.
> >>
> >> Can someone please explain and tell me how can I update and get rid of
> >> the denied messages?
> >>
> >> This is the proftpd.te rule it made:
> >>
> >> module proftpd 1.0;
> >>
> >> require {
> >>     type ftpd_t;
> >>     type crond_t;
> >>     type httpd_suexec_t;
> >>     class capability dac_override;
> >>     class key { write search };
> >> }
> >>
> >> #============= ftpd_t ==============
> >> allow ftpd_t crond_t:key search;
> >> allow ftpd_t httpd_suexec_t:key search;
> >> allow ftpd_t self:capability dac_override;
> >> allow ftpd_t self:key { write search };
> >
> > You don't seem to be allowing "link" permission above, which is what was
> > being denied by the audit messages you posted.
> >
> >> But I see crond, httpd and ftpd all there but this rule does nothing :(
> >
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
> 
> iD8DBQFGjC2Ui1lOcz5YUMgRAuctAJ9ud3yxGylHozKDgI3eIf3U7p1vTgCgpaem
> 3taj9Wm+FbUKTtzw1w5ksLs=
> =/2aU
> -----END PGP SIGNATURE-----
> 
-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Libsemanage dependency on version of Linux...

[Hasan Rezaul-CHR010]

[-- Attachment #1: Type: text/plain, Size: 662 bytes --]

Hi All,

I currently am running on Linux 2.6.14,  and I have
libsemanage-1.6.17-1

After discussing with Stephen Smalley, I learned that in order for
semanage to NOT create a "/previous" directory, I need to upgrade my
libsemanage library to version   1.9.2  or higher.

My question is:  is libsemanage version 1.9.2  dependent on a Linux
version newer than Linux 2.6.14 ???

What is the latest version of libsemanage that is supported in Linux
version 2.6.14 ?

Also, what are the latest versions of the following other libs supported
by Linux 2.6.14 : ?

checkpolicy
libsepol
libselinux
Policycoreutils

Thanks in advance,

- Rezaul.

[-- Attachment #2: Type: text/html, Size: 1946 bytes --]

Re: Libsemanage dependency on version of Linux...

[Stephen Smalley]

On Thu, 2007-07-12 at 15:03 -0400, Hasan Rezaul-CHR010 wrote:
> Hi All,
> 
> I currently am running on Linux 2.6.14,  and I have
> libsemanage-1.6.17-1
> 
> After discussing with Stephen Smalley, I learned that in order for
> semanage to NOT create a "/previous" directory, I need to upgrade my
> libsemanage library to version   1.9.2  or higher.
> 
> My question is:  is libsemanage version 1.9.2  dependent on a Linux
> version newer than Linux 2.6.14 ???
> 
> What is the latest version of libsemanage that is supported in Linux
> version 2.6.14 ?
> 
> Also, what are the latest versions of the following other libs
> supported by Linux 2.6.14 : ?
> 
> checkpolicy 
> libsepol 
> libselinux 
> Policycoreutils

Hi,

You should generally upgrade all of the core SELinux userland components
together to be safe, but newer versions of the SELinux core userland
should work fine on older kernels (at least for the stable branch).

You may wish to set the policy-version in
your /etc/selinux/semanage.conf file though to make sure that it is
generating the right policy version for your kernel (as reported by
cat /selinux/policyvers), especially if you are using an older SysVinit
that doesn't use the newer policy loading logic with automatic
downgrading.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Libsemanage dependency on version of Linux...

[Hasan Rezaul-CHR010]

Thanks Stephen,

So given the fact that I must use Linux Kernel 2.6.14  :

Are you saying that its okay for us to upgrade SELinux libs FROM  the
versions listed below TO the versions listed below while continuing to
use Linux Kernel 2.6.14 ?  In other words, the newer versions of the
SELinux-related libs DON'T depend on the version of the Linux kernel ?
I would like to upgrade the libs as described below, but I fear that the
new libs versions may not work correctly with Linux 2.6.14.

Please confirm...


libsemanage-1.6.17-1     =>  libsemanage-1.10.4
checkpolicy-1.33.1-2     =>  checkpolicy-1.34.3-x
libsepol-1.15.3-1        =>  libsepol-1.16.3-x
libselinux-1.33.4-2      =>  libselinux-1.34.10-x
policycoreutils-1.34.1-4 =>  policycoreutils-1.34.10-x 

Thanks,

- Rezaul.


-----Original Message-----
From: Stephen Smalley [mailto:sds@tycho.nsa.gov] 
Sent: Thursday, July 12, 2007 2:40 PM
To: Hasan Rezaul-CHR010
Cc: SE Linux
Subject: Re: Libsemanage dependency on version of Linux...

On Thu, 2007-07-12 at 15:03 -0400, Hasan Rezaul-CHR010 wrote:
> Hi All,
> 
> I currently am running on Linux 2.6.14,  and I have
> libsemanage-1.6.17-1
> 
> After discussing with Stephen Smalley, I learned that in order for
> semanage to NOT create a "/previous" directory, I need to upgrade my
> libsemanage library to version   1.9.2  or higher.
> 
> My question is:  is libsemanage version 1.9.2  dependent on a Linux
> version newer than Linux 2.6.14 ???
> 
> What is the latest version of libsemanage that is supported in Linux
> version 2.6.14 ?
> 
> Also, what are the latest versions of the following other libs
> supported by Linux 2.6.14 : ?
> 
> checkpolicy 
> libsepol 
> libselinux 
> Policycoreutils

Hi,

You should generally upgrade all of the core SELinux userland components
together to be safe, but newer versions of the SELinux core userland
should work fine on older kernels (at least for the stable branch).

You may wish to set the policy-version in
your /etc/selinux/semanage.conf file though to make sure that it is
generating the right policy version for your kernel (as reported by
cat /selinux/policyvers), especially if you are using an older SysVinit
that doesn't use the newer policy loading logic with automatic
downgrading.

-- 
Stephen Smalley
National Security Agency



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Libsemanage dependency on version of Linux...

[Stephen Smalley]

On Thu, 2007-07-12 at 15:48 -0400, Hasan Rezaul-CHR010 wrote:
> Thanks Stephen,
> 
> So given the fact that I must use Linux Kernel 2.6.14  :
> 
> Are you saying that its okay for us to upgrade SELinux libs FROM  the
> versions listed below TO the versions listed below while continuing to
> use Linux Kernel 2.6.14 ?  In other words, the newer versions of the
> SELinux-related libs DON'T depend on the version of the Linux kernel ?
> I would like to upgrade the libs as described below, but I fear that the
> new libs versions may not work correctly with Linux 2.6.14.
> 
> Please confirm...
> 
> 
> libsemanage-1.6.17-1     =>  libsemanage-1.10.4
> checkpolicy-1.33.1-2     =>  checkpolicy-1.34.3-x
> libsepol-1.15.3-1        =>  libsepol-1.16.3-x
> libselinux-1.33.4-2      =>  libselinux-1.34.10-x
> policycoreutils-1.34.1-4 =>  policycoreutils-1.34.10-x 

AFAIK, there should be no problems from such an upgrade, and if there
are, that's a bug.

Naturally, trying it out on a test machine first considered a good idea.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Libsemanage dependency on version of Linux...

[Stephen Smalley]

On Thu, 2007-07-12 at 15:39 -0400, Stephen Smalley wrote:
> On Thu, 2007-07-12 at 15:03 -0400, Hasan Rezaul-CHR010 wrote:
> > Hi All,
> > 
> > I currently am running on Linux 2.6.14,  and I have
> > libsemanage-1.6.17-1
> > 
> > After discussing with Stephen Smalley, I learned that in order for
> > semanage to NOT create a "/previous" directory, I need to upgrade my
> > libsemanage library to version   1.9.2  or higher.
> > 
> > My question is:  is libsemanage version 1.9.2  dependent on a Linux
> > version newer than Linux 2.6.14 ???
> > 
> > What is the latest version of libsemanage that is supported in Linux
> > version 2.6.14 ?
> > 
> > Also, what are the latest versions of the following other libs
> > supported by Linux 2.6.14 : ?
> > 
> > checkpolicy 
> > libsepol 
> > libselinux 
> > Policycoreutils
> 
> Hi,
> 
> You should generally upgrade all of the core SELinux userland components
> together to be safe, but newer versions of the SELinux core userland
> should work fine on older kernels (at least for the stable branch).
> 
> You may wish to set the policy-version in
> your /etc/selinux/semanage.conf file though to make sure that it is
> generating the right policy version for your kernel (as reported by
> cat /selinux/policyvers), especially if you are using an older SysVinit
> that doesn't use the newer policy loading logic with automatic
> downgrading.

BTW, any particular reason you are stuck on 2.6.14?  It is a fairly old
kernel, and even "stable" distributions like RHEL5 and Debian etch are
using 2.6.18 derivatives IIRC.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [patch 1/3] libsemanage: genhomedircon replacement

[James Antill]

[-- Attachment #1: Type: text/plain, Size: 1296 bytes --]

On Mon, 2007-07-02 at 10:00 -0400, Joshua Brindle wrote: 
> Eamon Walsh wrote:
> > Karl MacMillan wrote:
> >> Can I suggest a middle ground? Implement in C (or C++) but use a string
> >> library.
> > 
> > A library would be great, I'm still depressed about glib's 
> > abort-on-malloc making it unusable.  ustr was mentioned earlier as a 
> > possible library that could be used.
> 
> Unfortunately ustr isn't in yum so we'd have to pull code into the lib 
> itself, which I'd prefer not to.

 Right, it's not in Fedora's main repo. yet. But it should be "real soon
now".

> Additionally ustr's documentation is a 
> bit lacking: http://www.and.org/ustr/functions . Stuff like "This 
> function does nothing." in the docs is a bit disconcerting as well.

 Well I'm working on the documentation (and lack of it is one reason
I've held off putting it in the Fedora repo.), but there are examples
and test cases for every function. The function that did nothing was
ustr_pool_sys_free()[1], because you couldn't free an individual piece
of memory from a pool (just the pool itself).


[1] Which is now a virtual function of the pool, alas. the documentation
didn't get updated because I forgot I'd written documentation for it!

-- 
James Antill <jantill@redhat.com>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [patch 1/3] libsemanage: genhomedircon replacement

[James Antill]

[-- Attachment #1: Type: text/plain, Size: 1465 bytes --]

On Fri, 2007-06-22 at 12:58 -0400, Eamon Walsh wrote:
> Karl MacMillan wrote:
> > On Thu, 2007-06-21 at 16:54 -0400, Eamon Walsh wrote:
> > 
> >>   I'm not a fan of the Python dependencies.
> > 
> > Why?
> 
> Here's a nice example of RPM hell, courtesy of our Python dependency.  I 
> got this earlier in the year on one of my machines.
> 
> # yum -y upgrade
> --> Running transaction check
> --> Processing Dependency: gnutls-devel for package: libsoup-devel
> --> Processing Dependency: python(abi) = 2.4 for package: audit-libs-python
> --> Restarting Dependency Resolution with new changes.
> --> Populating transaction set with selected packages. Please wait.
> ---> Package gnutls-devel.i386 0:1.4.5-1 set to be updated
> --> Running transaction check
> --> Processing Dependency: python(abi) = 2.4 for package: audit-libs-python
> --> Finished Dependency Resolution
> Error: Missing Dependency: python(abi) = 2.4 is needed by package 
> audit-libs-python

 I'm not sure what this is trying to prove, the above is a
packaging/yum/rpm problem (which was fixed, IIRC).
 Also, again IIRC, it also has nothing to do with code being written in
python but because audit-libs-python / libselinux-python (which just
provide _bindings_ to the C API, and I don't think you are trying to
suggest we should remove those bindings) depend on an exact python-abi
and audit-libs / libselinux versions.

-- 
James Antill <jantill@redhat.com>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [patch 1/3] libsemanage: genhomedircon replacement

[Steve G]

<snip>
> > +	for (h = homedirs; h; h = h->next) {
> > +		s1len = strlen(h->data);
> > +		temp = malloc(s1len + sizeof("/[^/]*"));
> > +		strcpy(temp, h->data);
> > +		strcpy(temp + s1len, "/[^/]*");

could be:

for (h = homedirs; h; h = h->next) {
    asprintf(&temp, "%s/[^/]*", h->data);



> > +char *semanage_findval(char *file, char *var, char *delim)
> > +{
> > +	FILE *fd;
> > +
> > +	char *buff;
> > +	char *temp = NULL;
> > +
> > +	if (!file || !var || !delim)
> > +		return NULL;
> 
> assert?

Assert is bad as it calls SIGABRT. SIGABRT means dump core. Production software
should not be dumping core as a habit.

-Steve


       
____________________________________________________________________________________Sick sense of humor? Visit Yahoo! TV's 
Comedy with an Edge to see what's on, when. 
http://tv.yahoo.com/collections/222

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [patch 1/3] libsemanage: genhomedircon replacement

[Karl MacMillan]

On Thu, 2007-05-24 at 08:05 -0700, Steve G wrote:

> > > +char *semanage_findval(char *file, char *var, char *delim)
> > > +{
> > > +	FILE *fd;
> > > +
> > > +	char *buff;
> > > +	char *temp = NULL;
> > > +
> > > +	if (!file || !var || !delim)
> > > +		return NULL;
> > 
> > assert?
> 
> Assert is bad as it calls SIGABRT. SIGABRT means dump core. Production software
> should not be dumping core as a habit.
> 

Assert is perfectly acceptable for checking for "impossible" situations
that would lead to a crash anyway. The assert assures that the crash is
immediate and there is no memory corruption or misuse.

See my other mail - I'm trying to determine whether this is a check for
an impossible state or something that needs runtime error checking.

Karl



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [patch 1/3] libsemanage: genhomedircon replacement

[James Antill]

[-- Attachment #1: Type: text/plain, Size: 3037 bytes --]

On Thu, 2007-05-24 at 10:04 -0400, Mark Goldman wrote:
> <snip>
> > > +static int write_home_dir_context(FILE * out, list_t * tpl, char *user,
> > > +				  char *seuser, char *home, char *prefix)
> > > +{
> > > +	char *temp;
> > > +	char *line;
> > > +
> > > +	fprintf(out, "\n\n#\n# Home Context for user %s\n#\n\n", user);
> > > +	for (; tpl; tpl = tpl->next) {
> > > +		temp = semanage_sed(tpl->data, "HOME_DIR", home);
> > 
> > Wow - I understand that this string handling in C is painful, but is
> > this really the best alternative? Perhaps parsing the input to make the
> > substitution easier would be better? Perhaps we should look for some
> > library code to do this?
> I am not really sure what the problem with this is.  We need to replace
> arbitrary substrings.  I searched in the C libraries for something that
> might do what I want.  I couldn't find anything, so I wrote a function
> to do it.

 I feel your pain, doing anything non-trivial with strings in C is
always a major PITA.
 As a personal project I've almost got ustr[1] in a 1.0 release, which I
hope could be used in the SELinux libraries (being able to easily
integrate it into libraries, is one of it's main points), and would
solve this problem and others in the SELinux libs. (like the strdup() +
a bit more data).

> As for parsing the input to make the substitution easier, I think it
> would be a lot more work to write or use a full fledged parser.  What
> we want in this situation is what I wrote in my opinion, although I am
> open to suggestions.

 Saying that, there were more than a few problems with semanage_sed()
even if you discount the genericness of the name:

1. You pre-allocate a bad amount of space:

+       srclen = strlen(src);
+       maxdest = 2 * srclen;
+       dest = malloc(maxdest);

...consider:

HOME_DIR        -d      system_u:object_r:user_home_dir_t:s0

strlen("HOME_DIR") == 8, *2 == 16
strlen("/home/kmacmillan") == 16

...I think, you really want something like:

+       maxdest = srclen + (replen - vallen) * 2 + 1;


2. You pre-reallocate if there isn't enough room to insert a new val,
even if it's not possible to insert a new val:

+               min_increment = (dindex + replen + 1) - maxdest;
+               if (min_increment >= 0) {

...consider:

HOME_DIR/.+     system_u:object_r:user_home_t:s0

strlen("HOME_DIR/.+") == 11, *2 == 22
strlen("/home/james") == 11

...now when you are at '.' in the above substitution, you'll have
dindex=11 and replen=11 which will trigger a realloc() even though you
only have 2 bytes left in src (so HOME_DIR will never match, obviously).


3. You should probably be calling strstr() instead of walking the
string.


4. All the sizes are signed int's, and no overflow/underflow checking is
done. This might be safe due to current usage, but it seems like a bad
idea to leave it this way in a core security lib.


[1] http://www.and.org/ustr/

-- 
James Antill <jantill@redhat.com>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [patch 1/3] libsemanage: genhomedircon replacement

[Mark Goldman]

On Thu, 2007-05-24 at 12:00 -0400, James Antill wrote:
>  I feel your pain, doing anything non-trivial with strings in C is
> always a major PITA.
>  As a personal project I've almost got ustr[1] in a 1.0 release, which I
> hope could be used in the SELinux libraries (being able to easily
> integrate it into libraries, is one of it's main points), and would
> solve this problem and others in the SELinux libs. (like the strdup() +
> a bit more data).
I, personally wouldn't object.

> > As for parsing the input to make the substitution easier, I think it
> > would be a lot more work to write or use a full fledged parser.  What
> > we want in this situation is what I wrote in my opinion, although I am
> > open to suggestions.
> 
>  Saying that, there were more than a few problems with semanage_sed()
> even if you discount the genericness of the name:
> 
> 1. You pre-allocate a bad amount of space:
> 
> +       srclen = strlen(src);
> +       maxdest = 2 * srclen;
> +       dest = malloc(maxdest);
> 
> ...consider:
> 
> HOME_DIR        -d      system_u:object_r:user_home_dir_t:s0
> 
> strlen("HOME_DIR") == 8, *2 == 16
> strlen("/home/kmacmillan") == 16
> 
> ...I think, you really want something like:
> 
> +       maxdest = srclen + (replen - vallen) * 2 + 1;
> 
> 
> 2. You pre-reallocate if there isn't enough room to insert a new val,
> even if it's not possible to insert a new val:
> 
> +               min_increment = (dindex + replen + 1) - maxdest;
> +               if (min_increment >= 0) {
> 
> ...consider:
> 
> HOME_DIR/.+     system_u:object_r:user_home_t:s0
> 
> strlen("HOME_DIR/.+") == 11, *2 == 22
> strlen("/home/james") == 11
> 
> ...now when you are at '.' in the above substitution, you'll have
> dindex=11 and replen=11 which will trigger a realloc() even though you
> only have 2 bytes left in src (so HOME_DIR will never match, obviously).
> 
> 
> 3. You should probably be calling strstr() instead of walking the
> string.
> 
> 
> 4. All the sizes are signed int's, and no overflow/underflow checking is
> done. This might be safe due to current usage, but it seems like a bad
> idea to leave it this way in a core security lib.
> 
> 
> [1] http://www.and.org/ustr/

Points all well taken.

-mdg
  

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

[patch 2/3] libsemanage: test functions

[jbrindle]

Test functions for libsemanage/src/utilities.c and
libsemanage/src/utilities.h

Index: ghdc-clean/libsemanage/tests/test_utilities.c
===================================================================
--- /dev/null
+++ ghdc-clean/libsemanage/tests/test_utilities.c
@@ -0,0 +1,297 @@
+/* Authors: Mark Goldman <mgoldman@tresys.com>
+ *
+ * Copyright (C) 2007 Tresys Technology, LLC
+ *
+ *  This library is free software; you can redistribute it and/or
+ *  modify it under the terms of the GNU Lesser General Public
+ *  License as published by the Free Software Foundation; either
+ *  version 2.1 of the License, or (at your option) any later version.
+ *
+ *  This library is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ *  Lesser General Public License for more details.
+ *
+ *  You should have received a copy of the GNU Lesser General Public
+ *  License along with this library; if not, write to the Free Software
+ *  Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
+ */
+
+/*  The purpose of this file is to provide unit tests of the functions in:
+ *
+ *  libsemanage/src/utilities.c
+ *
+ */
+
+#include <CUnit/Basic.h>
+#include <CUnit/Console.h>
+#include <CUnit/TestDB.h>
+
+#include <stdio.h>
+#include <getopt.h>
+#include <stdlib.h>
+#include <string.h>
+#include <unistd.h>
+
+#include <utilities.h>
+
+void test_semanage_prefix_of(void);
+void test_semanage_split_on_space(void);
+void test_semanage_split(void);
+void test_semanage_list(void);
+void test_semanage_str_count(void);
+void test_semanage_rtrim(void);
+void test_semanage_findval(void);
+void test_slurp_file_filter(void);
+
+char fname[] = {
+	'T', 'E', 'S', 'T', '_', 'T', 'E', 'M', 'P', '_', 'X', 'X', 'X', 'X',
+	    'X', 'X'
+};
+int fd;
+FILE *fptr;
+
+int semanage_utilities_test_init(void)
+{
+
+	fd = mkstemp(fname);
+
+	if (fd < 0) {
+		perror("test_semanage_findval: ");
+		CU_FAIL_FATAL
+		    ("Error opening temporary file, test cannot start.");
+	}
+
+	fptr = fdopen(fd, "w+");
+	if (!fptr) {
+		perror("test_semanage_findval file: ");
+		CU_FAIL_FATAL("Error opening file stream, test cannot start.");
+	}
+
+	fprintf(fptr, "one\ntwo\nthree\nsigma=foo\n#boo\n#bar\n");
+
+	rewind(fptr);
+	return 0;
+}
+
+int semanage_utilities_test_cleanup(void)
+{
+	unlink(fname);
+	return 0;
+}
+
+int semanage_utilities_add_tests(CU_pSuite suite)
+{
+	if (NULL == CU_add_test(suite, "semanage_prefix_of",
+				test_semanage_prefix_of)) {
+		goto err;
+	}
+	if (NULL == CU_add_test(suite, "semanage_split_on_space",
+				test_semanage_split_on_space)) {
+		goto err;
+	}
+	if (NULL == CU_add_test(suite, "semanage_split", test_semanage_split)) {
+		goto err;
+	}
+	if (NULL == CU_add_test(suite, "semanage_list", test_semanage_list)) {
+		goto err;
+	}
+	if (NULL == CU_add_test(suite, "semanage_str_count",
+				test_semanage_str_count)) {
+		goto err;
+	}
+	if (NULL == CU_add_test(suite, "semanage_rtrim", test_semanage_rtrim)) {
+		goto err;
+	}
+	if (NULL == CU_add_test(suite, "semanage_findval",
+				test_semanage_findval)) {
+		goto err;
+	}
+	if (NULL == CU_add_test(suite, "slurp_file_filter",
+				test_slurp_file_filter)) {
+		goto err;
+	}
+	return 0;
+      err:
+	CU_cleanup_registry();
+	return CU_get_error();
+}
+
+void test_semanage_prefix_of(void)
+{
+	char *str = "some string";
+	char *pre = "some";
+	char *not_pre = "not this";
+
+	CU_ASSERT_TRUE(semanage_prefix_of(str, pre));
+	CU_ASSERT_TRUE(semanage_prefix_of(str, ""));
+	CU_ASSERT_TRUE(semanage_prefix_of(str, NULL));
+	CU_ASSERT_FALSE(semanage_prefix_of(str, not_pre));
+	return;
+}
+
+void test_semanage_split_on_space(void)
+{
+	char *str = strdup("foo bar baz");
+	char *temp;
+
+	if (!str) {
+		CU_FAIL
+		    ("semanage_split_on_space: unable to perform test, no memory");
+	}
+	temp = semanage_split_on_space(str);
+	if (strncmp(temp, "bar", 3)) {
+		CU_FAIL("semanage_split_on_space: token did not match");
+	}
+	temp = semanage_split_on_space(temp);
+	if (strncmp(temp, "baz", 3)) {
+		CU_FAIL("semanage_split_on_space: token did not match");
+	}
+	temp = semanage_split_on_space(temp);
+	if (strcmp(temp, "")) {
+		CU_FAIL("semanage_split_on_space: token did not match");
+	}
+
+	free(str);
+	return;
+}
+
+void test_semanage_split(void)
+{
+	char *str = strdup("foo1 foo2 foo:bar");
+	char *temp;
+
+	if (!str) {
+		CU_FAIL
+		    ("semanage_split_on_space: unable to perform test, no memory");
+		return;
+	}
+	temp = semanage_split(str, NULL);
+	CU_ASSERT_NSTRING_EQUAL(temp, "foo2", 4);
+	temp = semanage_split(temp, "");
+	CU_ASSERT_NSTRING_EQUAL(temp, "foo", 3);
+	temp = semanage_split(temp, ":");
+	CU_ASSERT_NSTRING_EQUAL(temp, "bar", 3);
+
+	free(str);
+	return;
+}
+
+
+void test_semanage_list(void)
+{
+	list_t *list = NULL;
+	list_t *ptr = NULL;
+	char *temp = NULL;
+	int retval = 0;
+
+	semanage_list_push(&list, "foo");
+	CU_ASSERT_PTR_NOT_NULL(list);
+	semanage_list_push(&list, "bar");
+	semanage_list_push(&list, "gonk");
+	semanage_list_push(&list, "zebra");
+
+	for (ptr = list; ptr; ptr = ptr->next)
+		retval++;
+	CU_ASSERT_EQUAL(retval, 4);
+
+	temp = semanage_list_pop(&list);
+	CU_ASSERT_STRING_EQUAL(temp, "zebra");
+	semanage_list_push(&list, temp);
+	free(temp);
+	temp = NULL;
+
+	retval = 0;
+	for (ptr = list; ptr; ptr = ptr->next)
+		retval++;
+	CU_ASSERT_EQUAL(retval, 4);
+
+	retval = semanage_list_sort(&list);
+	if (retval) {
+		CU_FAIL
+		    ("semanage_list_sort: error unrelated to sort (memory?)");
+		goto past_sort;
+	}
+	CU_ASSERT_STRING_EQUAL(list->data, "bar");
+	CU_ASSERT_STRING_EQUAL(list->next->data, "foo");
+	CU_ASSERT_STRING_EQUAL(list->next->next->data, "gonk");
+	CU_ASSERT_STRING_EQUAL(list->next->next->next->data, "zebra");
+
+      past_sort:
+	ptr = semanage_list_find(list, "zebra");
+	CU_ASSERT_PTR_NOT_NULL(ptr);
+	ptr = semanage_list_find(list, "bogus");
+	CU_ASSERT_PTR_NULL(ptr);
+
+	semanage_list_destroy(&list);
+	CU_ASSERT_PTR_NULL(list);
+	return;
+}
+
+
+void test_semanage_str_count(void)
+{
+	char *test_string = "abaababbaaaba";
+
+	CU_ASSERT_EQUAL(semanage_str_count(test_string, 'z'), 0);
+	CU_ASSERT_EQUAL(semanage_str_count(test_string, 'a'), 8);
+	CU_ASSERT_EQUAL(semanage_str_count(test_string, 'b'), 5);
+}
+
+void test_semanage_rtrim(void)
+{
+	char *str = strdup("/blah/foo/bar/baz/");
+
+	CU_ASSERT_PTR_NOT_NULL_FATAL(str);
+
+	semanage_rtrim(str, 'Q');
+	CU_ASSERT_STRING_EQUAL(str, "/blah/foo/bar/baz/");
+	semanage_rtrim(str, 'a');
+	CU_ASSERT_STRING_EQUAL(str, "/blah/foo/bar/b");
+	semanage_rtrim(str, '/');
+	CU_ASSERT_STRING_EQUAL(str, "/blah/foo/bar");
+	return;
+}
+
+
+
+void test_semanage_findval(void)
+{
+	char *tok;
+	if (!fptr) {
+		CU_FAIL_FATAL("Temporary file was not created, aborting test.");
+	}
+	tok = semanage_findval(fname, "one", NULL);
+	CU_ASSERT_PTR_NULL(tok);
+	rewind(fptr);
+	tok = semanage_findval(fname, "one", "");
+	CU_ASSERT_STRING_EQUAL(tok, "");
+	free(tok);
+	rewind(fptr);
+	tok = semanage_findval(fname, "sigma", "=");
+	CU_ASSERT_STRING_EQUAL(tok, "foo");
+}
+
+
+int PREDICATE(char *str)
+{
+	return semanage_prefix_of(str, "#");
+}
+
+void test_slurp_file_filter(void)
+{
+	list_t *data, *tmp;
+	int cnt = 0;
+
+	if (!fptr) {
+		CU_FAIL_FATAL("Temporary file was not created, aborting test.");
+	}
+	rewind(fptr);
+	data = slurp_file_filter(fptr, PREDICATE);
+	CU_ASSERT_PTR_NOT_NULL_FATAL(data);
+	for (tmp = data; tmp; tmp = tmp->next)
+		cnt++;
+	CU_ASSERT_EQUAL(cnt, 2);
+
+	semanage_list_destroy(&data);
+}
Index: ghdc-clean/libsemanage/tests/libsemanage-tests.c
===================================================================
--- ghdc-clean.orig/libsemanage/tests/libsemanage-tests.c
+++ ghdc-clean/libsemanage/tests/libsemanage-tests.c
@@ -20,6 +20,7 @@
  */
 
 #include "test_semanage_store.h"
+#include "test_utilities.h"
 
 #include <CUnit/Basic.h>
 #include <CUnit/Console.h>
@@ -55,6 +56,7 @@ static int do_tests(int interactive, int
 		return CU_get_error();
 
 	DECLARE_SUITE(semanage_store);
+	DECLARE_SUITE(semanage_utilities);
 
 	if (verbose)
 		CU_basic_set_mode(CU_BRM_VERBOSE);
Index: ghdc-clean/libsemanage/tests/test_utilities.h
===================================================================
--- /dev/null
+++ ghdc-clean/libsemanage/tests/test_utilities.h
@@ -0,0 +1,5 @@
+#include <CUnit/Basic.h>
+
+int semanage_utilities_test_init(void);
+int semanage_utilities_test_cleanup(void);
+int semanage_utilities_add_tests(CU_pSuite suite);

-- 

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

[patch 3/3] Remove legacy genhomedircon python script

[jbrindle]

Index: ghdc/policycoreutils/scripts/Makefile
===================================================================
--- ghdc.orig/policycoreutils/scripts/Makefile
+++ ghdc/policycoreutils/scripts/Makefile
@@ -5,18 +5,14 @@ SBINDIR ?= $(PREFIX)/sbin
 MANDIR ?= $(PREFIX)/share/man
 LOCALEDIR ?= /usr/share/locale
 
-TARGETS=genhomedircon 
-
-all: $(TARGETS) fixfiles
+all: fixfiles
 
 install: all
 	-mkdir -p $(BINDIR)
-	install -m 755 $(TARGETS) $(SBINDIR)
 	install -m 755 chcat $(BINDIR)
 	install -m 755 fixfiles $(DESTDIR)/sbin
 	-mkdir -p $(MANDIR)/man8
 	install -m 644 fixfiles.8 $(MANDIR)/man8/
-	install -m 644 genhomedircon.8 $(MANDIR)/man8/
 	install -m 644 chcat.8 $(MANDIR)/man8/
 
 clean:
Index: ghdc/policycoreutils/scripts/genhomedircon
===================================================================
--- ghdc.orig/policycoreutils/scripts/genhomedircon
+++ /dev/null
@@ -1,386 +0,0 @@
-#! /usr/bin/python -E
-# Copyright (C) 2004 Tresys Technology, LLC
-# see file 'COPYING' for use and warranty information
-#
-# genhomedircon - this script is used to generate file context
-# configuration entries for user home directories based on their
-# default prefixes and is run when building the policy. Specifically, we
-# replace HOME_ROOT, HOME_DIR, and ROLE macros in .fc files with
-# generic and user-specific values.
-#
-# Based off original script by Dan Walsh, <dwalsh@redhat.com>
-#
-# ASSUMPTIONS:
-#
-# The file CONTEXTDIR/files/homedir_template exists.  This file is used to
-# set up the home directory context for each real user.
-# 
-# If a user is not listed in CONTEXTDIR/seusers, he will default to user_u, prefix user
-#
-# "Real" users (as opposed to system users) are those whose UID is greater than
-#  or equal STARTING_UID (usually 500) and whose login is not a member of
-#  EXCLUDE_LOGINS.  Users who are explicitly defined in CONTEXTDIR/seusers
-#  are always "real" (including root, in the default configuration).
-#
-#  
-
-import sys, os, pwd, string, getopt, re
-from semanage import *;
-import gettext
-gettext.install('policycoreutils')
-
-def grep(file, var):
-	ret = ""
-	fd = open(file, 'r')
-
-	for i in  fd.readlines():
-	    if re.search(var, i, 0) != None:
-	        ret = i
-                break
-	fd.close()
-	return ret
-
-def findval(file, var, delim = ""):
-	val = ""
-	try:
-		fd = open(file, 'r')
-		for i in  fd.readlines():
-			if i.startswith(var) == 1:
-				if delim == "":
-					val = i.split()[1]
-				else:
-					val = i.split(delim)[1]
-				val = val.split("#")[0]
-				val = val.strip()
-		fd.close()
-	except:
-		val = ""
-	return val
-
-def getStartingUID():
-	starting_uid = sys.maxint
-	uid_min =  findval("/etc/login.defs", "UID_MIN")
-	if uid_min != "":
-		uid_min = uid_min.split("#")[0]
-		uid_min = uid_min.strip()
-		if int(uid_min) < starting_uid:
-			starting_uid = int(uid_min)
-
-	uid_min =  findval("/etc/libuser.conf", "LU_UIDNUMBER", "=")
-	if uid_min != "":
-		uid_min = uid_min.split("#")[0]
-		uid_min = uid_min.strip()
-		if int(uid_min) < starting_uid:
-			starting_uid = int(uid_min)
-
-	if starting_uid == sys.maxint:
-		starting_uid = 500
-	return starting_uid
-
-def getDefaultHomeDir():
-	ret = []
-	homedir = findval("/etc/default/useradd", "HOME", "=")
-	if homedir != "" and not homedir in ret:
-		ret.append(homedir)
-	
-	homedir = findval("/etc/libuser.conf", "LU_HOMEDIRECTORY", "=")
-	if homedir != "" and not homedir in ret:
-		ret.append(homedir)
-	
-	if ret == []:
-		ret.append("/home")
-
-	# Add /export/home if it exists
-	# Some customers use this for automounted homedirs
-	if os.path.exists("/export/home"):
-		ret.append("/export/home")
-
-	return ret
-
-def getSELinuxType(directory):
-	val = findval(directory+"/config", "SELINUXTYPE", "=")
-	if val != "":
-		return val
-	return "targeted"
-
-def usage(rc=0, error = ""):
-	if error != "":
-		sys.stderr.write("%s\n" % error)
-		rc = 1
-	sys.stderr.write("Usage: %s [ -d selinuxdir ] [-n | --nopasswd] [-t selinuxtype ]\n" % sys.argv[0])
-	sys.stderr.flush()
-	sys.exit(rc)
-
-def warning(warning = ""):
-	sys.stderr.write("%s\n" % warning)
-	sys.stderr.flush()
-	
-def errorExit(error):
-	sys.stderr.write("%s exiting for: " % sys.argv[0])
-	sys.stderr.write("%s\n" % error)
-	sys.stderr.flush()
-	sys.exit(1)
-
-class selinuxConfig:
-	def __init__(self, selinuxdir = "/etc/selinux", type = "targeted", usepwd = 1):
-		self.semanageHandle = semanage_handle_create()
-		self.semanaged = semanage_is_managed(self.semanageHandle)
-		if self.semanaged:
-			rc = semanage_connect(self.semanageHandle)
-			if rc:
-				errorExit("Unable to connect to semanage")
-			(status, self.ulist) = semanage_user_list(self.semanageHandle)
-		self.type = type
-		self.selinuxdir = selinuxdir +"/"
-		self.contextdir = "/contexts"
-		self.filecontextdir = self.contextdir+"/files"
-		self.usepwd = usepwd
-
-	def getFileContextDir(self):
-		return self.selinuxdir+self.type+self.filecontextdir
-
-	def getFileContextFile(self):
-		return self.getFileContextDir()+"/file_contexts"
-	
-	def getContextDir(self):
-		return self.selinuxdir+self.type+self.contextdir
-
-	def getHomeDirTemplate(self):
-		return self.getFileContextDir()+"/homedir_template"
-
-	def getHomeRootContext(self, homedir):
-		ret = ""
-		fd = open(self.getHomeDirTemplate(), 'r')
-
-		for i in  fd.readlines():
-			if i.find("HOME_ROOT") == 0:
-				i = i.replace("HOME_ROOT", homedir)
-				ret += i
-		fd.close()
-		if ret == "":
-			errorExit("No Home Root Context Found")
-		return ret
-
-	def heading(self):
-		ret = "\n#\n#\n# User-specific file contexts, generated via %s\n" % sys.argv[0]
-		if self.semanaged:
-			ret += "# use semanage command to manage system users in order to change the file_context\n#\n#\n"
-		else:
-			ret += "# edit %s to change file_context\n#\n#\n" % (self.selinuxdir+self.type+"/seusers")
-		return ret
-
-	def get_default_prefix(self, name):
-		for user in self.ulist:
-			if semanage_user_get_name(user) == name:
-				return semanage_user_get_prefix(user)
-		return name
-
-	def get_old_prefix(self, user):
-		rc = grep(self.selinuxdir+self.type+"/users/system.users", "^user %s" % user)
-		if rc == "":					    
-			rc = grep(self.selinuxdir+self.type+"/users/local.users", "^user %s" % user)
-		if rc != "":
-			user = rc.split()
-			prefix  =  user[3]
-			if prefix == "{":
-				prefix = user[4]
-		if len(prefix) > 2 and (prefix[-2:] == "_r" or prefix[-2:] == "_u"):
-			prefix = prefix[:-2]
-		return prefix
-		
-	def adduser(self, udict, user, seuser, prefix):
-		if seuser == "user_u" or user == "__default__" or user == "system_u":
-			return
-		# !!! chooses first prefix in the list to use in the file context !!!
-		try:
-			home = pwd.getpwnam(user)[5]
-			if home == "/":
-				# Probably install so hard code to /root
-				if user == "root":
-					home = "/root"
-				else:
-					return
-		except KeyError:
-			if user == "root":
-				home = "/root"
-			else:
-				sys.stderr.write("The user \"%s\" is not present in the passwd file, skipping...\n" % user)
-				return
-		prefs = {}
-		prefs["seuser"] = seuser
-		prefs["prefix"] = prefix
-		prefs["home"] = home
-		udict[user] = prefs
-		
-	def getUsers(self):
-		udict = {}
-		if self.semanaged:
-			(status, list) = semanage_seuser_list(self.semanageHandle)
-			for seuser in list:
-				user = []
-				seusername = semanage_seuser_get_sename(seuser)
-				self.adduser(udict, semanage_seuser_get_name(seuser), seusername, self.get_default_prefix(seusername))
-				
-		else:
-			try:
-				fd = open(self.selinuxdir+self.type+"/seusers")
-				for u in  fd.readlines():
-					u = u.strip()
-					if len(u) == 0 or u[0] == "#":
-						continue
-					user = u.split(":")
-					if len(user) < 2:
-						continue
-					
-					prefix = self.get_old_prefix(user[1])
-					self.adduser(udict, user[0], user[1], prefix)
-				fd.close()
-			except IOError, error:
-				# Must be install so force add of root
-				self.adduser(udict, "root", "root", "root")
-
-		return udict
-
-	def getHomeDirContext(self, user, seuser, home, prefix):
-		ret = "\n\n#\n# Home Context for user %s\n#\n\n" % user
-		fd = open(self.getHomeDirTemplate(), 'r')
-		for i in  fd.readlines():
-			if i.startswith("HOME_DIR") == 1:
-				i = i.replace("HOME_DIR", home)
-				i = i.replace("ROLE", prefix)
-				i = i.replace("system_u", seuser)
-				ret = ret+i
-		fd.close()
-		return ret
-
-	def getUserContext(self, user, sel_user, prefix):
-		ret = ""
-		fd = open(self.getHomeDirTemplate(), 'r')
-		for i in  fd.readlines():
-			if i.find("USER") == 1:
-				i = i.replace("USER", user)
-				i = i.replace("ROLE", prefix)
-				i = i.replace("system_u", sel_user)
-				ret = ret+i
-		fd.close()
-		return ret
-
-	def genHomeDirContext(self):
-		users = self.getUsers()
-		ret = ""
-		# Fill in HOME and prefix for users that are defined
-		for u in users.keys():
-			ret += self.getHomeDirContext (u, users[u]["seuser"], users[u]["home"], users[u]["prefix"])
-			ret += self.getUserContext (u, users[u]["seuser"], users[u]["prefix"])
-		return ret+"\n"
-
-	def checkExists(self, home):
-		fd = open(self.getFileContextFile())
-		for i in  fd.readlines():
-                    if len(i) == 0:
-			    continue
-		    try:
-			    regex = i.split()[0]
-			    #match a trailing .+
-			    regex = re.sub("\.+$", "", regex)
-			    regex = re.sub("\.\*$", "", regex)
-			    #strip a (/.*)? which matches anything trailing to a /*$ which matches trailing /'s
-			    
-			    regex = re.sub("\(\/\.\*\)\?", "", regex)
-			    regex = regex + "/*$"
-			    if re.search(home, regex, 0):
-				    return 1
-		    except:
-			    continue
-		return 0
-
-	def getHomeDirs(self):
-		homedirs = getDefaultHomeDir()
-		starting_uid = getStartingUID()
-		if self.usepwd == 0:
-			return homedirs
-		ulist = pwd.getpwall()
-		for u in ulist:
-			if u[2] >= starting_uid and \
-					u[6] in VALID_SHELLS and \
-					u[5] != "/" and \
-					string.count(u[5], "/") > 1:
-				homedir = u[5][:string.rfind(u[5], "/")]
-				if not homedir in homedirs:
-					if self.checkExists(homedir) == 1:
-						warning("%s homedir %s or its parent directory conflicts with a\ndefined context in %s,\n%s will not create a new context. This usually indicates an incorrectly defined system account.  If it is a system account please make sure its login shell is /sbin/nologin." % (u[0], u[5], self.getFileContextFile(), sys.argv[0]))
-					else:
-						homedirs.append(homedir)
-
-		homedirs.sort()
-		return homedirs
- 
-	def genoutput(self):
-		ret = self.heading()
-		for h in self.getHomeDirs():
-			ret += self.getHomeDirContext ("user_u", "user_u" , h+'/[^/]*', "user")
-			ret += self.getHomeRootContext(h)
-		ret += self.getUserContext(".*", "user_u", "user") + "\n"
-		ret += self.genHomeDirContext()
-		return ret
-
-	def printout(self):
-		print self.genoutput()
-
-	def write(self):
-		fd = open(self.getFileContextDir()+"/file_contexts.homedirs", "w")
-		fd.write(self.genoutput())
-		fd.close()
-
-if os.getuid() > 0 or os.geteuid() > 0:
-	print _("You must be root to run %s.") % sys.argv[0]
-	sys.exit(1)
-
-try:
-	fd = open("/etc/shells", 'r')
-	VALID_SHELLS = fd.read().split("\n")
-	fd.close()
-	if "/sbin/nologin" in VALID_SHELLS:
-		VALID_SHELLS.remove("/sbin/nologin")
-	if "" in VALID_SHELLS:
-		VALID_SHELLS.remove("")
-except:
-	VALID_SHELLS = ['/bin/sh', '/bin/bash', '/bin/ash', '/bin/bsh', '/bin/ksh', '/usr/bin/ksh', '/usr/bin/pdksh', '/bin/tcsh', '/bin/csh', '/bin/zsh']
-
-#
-# This script will generate home dir file context
-# based off the homedir_template file, entries in the password file, and
-#
-try:
-	usepwd = 1
-	directory = "/etc/selinux"
-	type = None
-	gopts, cmds = getopt.getopt(sys.argv[1:], 'hnd:t:', ['help',
-						'type=',
-						'nopasswd',
-						'dir='])
-	for o,a in gopts:
-		if o == '--type' or o == "-t":
-			type = a
-		if o == '--nopasswd'  or o == "-n":
-			usepwd = 0
-		if o == '--dir'  or o == "-d":
-			directory = a
-		if o == '--help'  or o == "-h":
-			usage()
-except getopt.error, error:
-	errorExit(_("Options Error %s ") % error)
-
-if type == None:
-	type = getSELinuxType(directory)
-
-if len(cmds) != 0:
-	usage(1)
-
-selconf = selinuxConfig(directory, type, usepwd)
-try:
-	selconf.write()
-except IOError, error:
-	sys.stderr.write("%s: %s\n" % ( sys.argv[0], error ))
-	sys.exit(1)
-
Index: ghdc/policycoreutils/scripts/genhomedircon.8
===================================================================
--- ghdc.orig/policycoreutils/scripts/genhomedircon.8
+++ /dev/null
@@ -1,82 +0,0 @@
-.\" Hey, Emacs! This is an -*- nroff -*- source file.
-.\" Copyright (c) 2005 Manoj Srivastava <srivasta@debian.org>
-.\"
-.\" This is free documentation; you can redistribute it and/or
-.\" modify it under the terms of the GNU General Public License as
-.\" published by the Free Software Foundation; either version 2 of
-.\" the License, or (at your option) any later version.
-.\"
-.\" The GNU General Public License's references to "object code"
-.\" and "executables" are to be interpreted as the output of any
-.\" document formatting or typesetting system, including
-.\" intermediate and printed output.
-.\"
-.\" This manual is distributed in the hope that it will be useful,
-.\" but WITHOUT ANY WARRANTY; without even the implied warranty of
-.\" MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-.\" GNU General Public License for more details.
-.\"
-.\" You should have received a copy of the GNU General Public
-.\" License along with this manual; if not, write to the Free
-.\" Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139,
-.\" USA.
-.\"
-.\"
-.TH GENHOMEDIRCON "8" "January 2005" "Security Enhanced Linux" ""
-.SH NAME
-genhomedircon \- generate SELinux file context configuration entries for user home directories 
-.SH SYNOPSIS
-.B genhomedircon [ -d selinuxdir ] [-n | --nopasswd] [-t selinuxtype ] [-h]
-
-.SH OPTIONS
-.TP
-.B "\-h"
-Print a short usage message
-.TP
-.B "\-d selinuxdir (\-\-directory)"
-Directory where selinux files are installed defaults to /etc/selinux
-.TP
-.B 
-\-n \-\-nopasswd
-Indicates to the utility not to read homedirectories out of the password database.  
-.TP
-\-t selinuxtype (\-\-type)
-Indicates the selinux type of this install.  Defaults to "targeted".
-.SH DESCRIPTION
-.PP
-This utility is used to generate file context configuration entries for 
-user home directories based on their 
-.B prefix 
-entry in the the 
-.B semanage user record.  
-genhomedircon is run when building 
-the policy. It is also run automaticaly when ever the 
-.B semanage 
-utility modifies 
-.B user
-or
-.B login
-records.
-Specifically, we replace HOME_ROOT, HOME_DIR, and ROLE macros in the 
-.I /etc/selinux/<<SELINUXTYPE>>/contexts/files/homedir_template 
-file with generic and user-specific values.  HOME_ROOT and HOME_DIR is replaced with each distinct location where login users homedirectories are located.  Defaults to /home. ROLE is replaced based on the prefix entry in the 
-.B user
-record.
-.PP 
-genhomedircon searches through all password entires for all "login" user home directories, (as opposed
-to system users).  Login users are those whose UID is greater than or equal 
-.I STARTING_UID
-(default 500) and whose login shell is not "/sbin/nologin", or
-"/bin/false". 
-.PP 
-.SH AUTHOR
-This manual page was originally written by 
-.I Manoj Srivastava <srivasta@debian.org>,
-for the Debian GNU/Linux system, based on the comments and the code
-in the utility, and then updated by Dan Walsh of Red Hat. The 
-.B genhomedircon
-utility was originally written by 
-.I Dan Walsh of Red Hat 
-with some modifications by 
-.I Tresys Technology, LLC.
-

-- 

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [patch 0/3] genhomedircon replacement in libsemanage

[Daniel J Walsh]

jbrindle@tresys.com wrote:
> This replaces genhomedircon with equivalent functionality in libsemanage. The homedir_template is also no longer installed, this leaves some unused path functions in libselinux but removing those would break the ABI. 
>
> This does the same things that genhomedircon did though some seemed strange, like removing /sbin/nologin from the list of valid shells, presumably to keep ftp users and such from getting file contexts generated for them, I'm not sure how valid the assumption is but we didn't want to change the functionality of genhomedircon in this patch set.
>
> The first patch adds genhomedircon.c to libsemanage and calls it from the semanage_store.c and removes the prior call to genhomedircon.
>   
genhomedircon goal in life was to find "login user accounts" and 
generate appropriate file context for them.  So we do not want any users 
with UID < 500 or with invalid shells.  /bin/nologin is not a valid 
login shell.  genhomedir command should be kept around even if it is 
only front-ending libsemanage.  Since an admin can add additional users 
with homedirs in random locations.  They could/should then run 
genhomedircon to fix the file context file.
> The second patch is a set of tests for the new functions
>
> And the third patch removes the old genhomedircon script.
>
>
> Signed-Off-By: Joshua Brindle <jbrindle@tresys.com>
>
>   


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [patch 0/3] genhomedircon replacement in libsemanage

[Joshua Brindle]

Daniel J Walsh wrote:
> jbrindle@tresys.com wrote:
>> This replaces genhomedircon with equivalent functionality in 
>> libsemanage. The homedir_template is also no longer installed, this 
>> leaves some unused path functions in libselinux but removing those 
>> would break the ABI.
>> This does the same things that genhomedircon did though some seemed 
>> strange, like removing /sbin/nologin from the list of valid shells, 
>> presumably to keep ftp users and such from getting file contexts 
>> generated for them, I'm not sure how valid the assumption is but we 
>> didn't want to change the functionality of genhomedircon in this patch 
>> set.
>>
>> The first patch adds genhomedircon.c to libsemanage and calls it from 
>> the semanage_store.c and removes the prior call to genhomedircon.
>>   
> genhomedircon goal in life was to find "login user accounts" and 
> generate appropriate file context for them.  So we do not want any users 
> with UID < 500 or with invalid shells.  /bin/nologin is not a valid 
> login shell.  genhomedir command should be kept around even if it is 
> only front-ending libsemanage.  Since an admin can add additional users 
> with homedirs in random locations.  They could/should then run 
> genhomedircon to fix the file context file.
>> The second patch is a set of tests for the new functions
>>

Why is /bin/nologin in /etc/shells then? Our code is now making 
assumptions about what shells are indeed valid that isn't based on what 
the system itself says.

semanage -Bn will rebuild the file context files (and the rest of the 
policy) which includes running genhomedircon. No need for an external 
command to do this.

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [patch 0/3] genhomedircon replacement in libsemanage

[Karl MacMillan]

On Tue, 2007-05-22 at 13:35 -0400, Joshua Brindle wrote:
> Daniel J Walsh wrote:
> > jbrindle@tresys.com wrote:
> >> This replaces genhomedircon with equivalent functionality in 
> >> libsemanage. The homedir_template is also no longer installed, this 
> >> leaves some unused path functions in libselinux but removing those 
> >> would break the ABI.
> >> This does the same things that genhomedircon did though some seemed 
> >> strange, like removing /sbin/nologin from the list of valid shells, 
> >> presumably to keep ftp users and such from getting file contexts 
> >> generated for them, I'm not sure how valid the assumption is but we 
> >> didn't want to change the functionality of genhomedircon in this patch 
> >> set.
> >>
> >> The first patch adds genhomedircon.c to libsemanage and calls it from 
> >> the semanage_store.c and removes the prior call to genhomedircon.
> >>   
> > genhomedircon goal in life was to find "login user accounts" and 
> > generate appropriate file context for them.  So we do not want any users 
> > with UID < 500 or with invalid shells.  /bin/nologin is not a valid 
> > login shell.  genhomedir command should be kept around even if it is 
> > only front-ending libsemanage.  Since an admin can add additional users 
> > with homedirs in random locations.  They could/should then run 
> > genhomedircon to fix the file context file.
> >> The second patch is a set of tests for the new functions
> >>
> 
> Why is /bin/nologin in /etc/shells then? Our code is now making 
> assumptions about what shells are indeed valid that isn't based on what 
> the system itself says.
> 


You should ask this question on the fedora-devel list.

Karl



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [patch 0/3] genhomedircon replacement in libsemanage

[Karl MacMillan]

On Mon, 2007-05-21 at 05:54 -0400, jbrindle@tresys.com wrote:
> This replaces genhomedircon with equivalent functionality in libsemanage. The homedir_template is also no longer installed, this leaves some unused path functions in libselinux but removing those would break the ABI. 
> 
> This does the same things that genhomedircon did though some seemed strange, like removing /sbin/nologin from the list of valid shells, presumably to keep ftp users and such from getting file contexts generated for them, I'm not sure how valid the assumption is but we didn't want to change the functionality of genhomedircon in this patch set.
> 
> The first patch adds genhomedircon.c to libsemanage and calls it from the semanage_store.c and removes the prior call to genhomedircon.
> 
> The second patch is a set of tests for the new functions
> 
> And the third patch removes the old genhomedircon script.
> 
> 
> Signed-Off-By: Joshua Brindle <jbrindle@tresys.com>
> 

The patch author should sign off on this instead of you.

Karl



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.