Tetsuo Handa
from-****@I-lov*****
Thu Dec 23 19:36:03 JST 2010
Jamie Nguyen wrote: > Yes, sounds good. Would save many lines, as a lot of my patterns are like: > /foo/ > /foo/\* > /foo/\{\*\}/ > /foo/\{\*\}/\* > > This could be done with one line: > rewrite head_pattern /foo/ @bar OK. You want to use 'head_pattern pathname @group_name' usage. Well, regarding CONFIG_SECURITY_PATH=n case (e.g. AKARI on RHEL6), the pathname looks like dev(majopr,minor):/foo/file and therefore 'head_pattern /foo/ @bar' won't work as expected. We need some tricks here. > Yes, when the firefox related lines go after reject_003.log then it > doesn't work. If I move the firefox lines before then it works fine. This is because evaluation stops at first chunk which matched all conditions. Chunks with stricter conditions have to be defined prior to chunks with looser conditions. > The first time I was faced with this warning, I didn't know what I had > to do to register the program. I've changed the warning message in > ccs-loadpolicy.c to recommend a reboot. > > Also, concerning warning messages, I have slightly changed some of the > warnings for ccs-patch 1.8.x to improve meaning/grammar. Yes, I received notices via tomoyo-svn ML. > However, for > the 2.x branch, I am unsure where changes should go. From what I > understand, TOMOYO 2.3 is for kernel 2.6.36, and TOMOYO 2.4 is for > kernel 2.6.37 . Because any corrections I make are going to be purely > aesthetic, I think I will only make changes in TOMOYO before the next > merge window, which is TOMOYO 2.5 for kernel 2.6.38 . What is your > workflow for submitting patches for the merge window (e.g. when will > you start putting together the patches for next merge window) and > which directory of SVN do your patches go? I am guessing "tags/lkml". Merge window for 2.6.37 was already closed. Thus, 2.6.37 remains TOMOYO 2.3. Merge window for 2.6.38 will open in January, but it is too soon to reflect TOMOYO 1.7 -> TOMOYO 1.8 changes. Thus, 2.6.38 will remain TOMOYO 2.3. 2.6.39 might reflect TOMOYO 1.7 -> TOMOYO 1.8 changes, but that is not now. > > At first, policy directory was hard coded and reading from stdin was not > > supported. But nowadays, policy location varies so much and reading from stdin > > is used commonly. Maybe it is time to make ccs-loadpolicy forget about policy > > directory. > > Is it OK to forbid ccs-loadpolicy without one of -d -e -m -p -s options > > (which results in forcing users to use pipe or redirection like > > > > ccs-loadpolicy -m < /etc/ccs/manager.conf > > > > rather than > > > > ccs-loadpolicy m > > > > )? > > Yes, I think ccs-loadpolicy should require an option. Excuse me, I want to confirm. Do you agree with forcing users to use pipe or redirection when using ccs-loadpolicy ? > According to the man page, I notice that "m", "p" and "s" options do > not have the choice to include the "f" option. The man page reads: > p : Read from policy_dir/profile.conf and append to /proc/ccs/profile > m : Read from policy_dir/manage.conf and append to /proc/ccs/profile > s: Read from policy_dir/stat.conf and append to /proc/ccs/stat > > I see that there is no "if (refresh_policy)" for these options, so > from my understanding they do not actually append, but instead > overwrite by default. I have changed ccs-loadpolicy options to reflect > this. Am right in thinking help2man will automatically reflect the > changes in the man page? Sorry, commit 4238 needs reconsideration. ccs-loadpolicy does not provide 'f' option for /proc/ccs/manager and /proc/ccs/profile in case the user misoperated. The user can likely recover from "ccs-loadpolicy -df < /dev/null" or "ccs-loadpolicy -ef < /dev/null" errors but cannot recover from "ccs-loadpolicy -pf < /dev/null" or "ccs-loadpolicy -mf < /dev/null" errors. If all entries were removed from /proc/ccs/manager and /proc/ccs/manager was closed by error before new entries are added to /proc/ccs/manager, the user will no longer be able to write to /proc/ccs/ interface, which forces the user to reboot the system. A profile can be modified after it was created but it can never be deleted. This is because we cannot delete profiles which are already in use by domains. If all profiles were removed from /proc/ccs/profile and /proc/ccs/profile was closed by error before new profiles are added to /proc/ccs/manager, domains can no longer work. TOMOYO's policy manipulation style is diff-like (e.g. write some_command some_arguments to add and write delete some_command some_arguments to delete). With 'f' option, ccs-loadpolicy automatically issues "delete" against old entries which are not defined in new entries. Without 'f' option, ccs-loadpolicy does not issue "delete" against old entries which are not defined in new entries. Regarding 'm' and 'p' options, I'm forcing the user to explicitly issue "delete" so that the user knows what they are doing. Regards.