[lkml]   [2008]   [Nov]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [TOMOYO #12 (2.6.28-rc2-mm1) 05/11] Memory and pathname management functions.
Andrew Morton wrote:
>> Are you saying "make the callers of tmy_alloc() tolerable with
>> uninitialized memory"?
> Well. That would be a desirable objective. I can understand the
> reasons for taking the easy way out. Given that Tomoyo doesn't seem to
> ever free memory again, one hopes that this function doesn't get called
> a lot, so the performance impact of zeroing out all that memory should
> be negligible.
> I think. Maybe I misinterpreted tmy_alloc(), and perhaps it _is_
> called frequently?
It is called whenever open() / mkdir() / unlink() etc. are called,
but not when read() / write() are called.
Frequency of open() / mkdir() / unlink() etc. are much lower than frequency of
read() / write().
Main cost of pathname based access control is strcmp()ing (or even regexp()ing)
over the list of strings, therefore zeroing buffer for pathname is relatively

>>>> Creating pseudo files for each variables is fine, though I don't see
>>>> advantage by changing from
>>>> "echo Shared: 16777216 > /sys/kernel/security/tomoyo/meminfo" to
>>>> "echo 16777216 > /sys/kernel/security/tomoyo/quota/shared_memory".
>>> Well for starters, the existing interface is ugly as sin and will make
>>> kernel developers unhappy.
>>> There is a pretty strict one-value-per-file rule in sysfs files, and
>>> "multiple tagged values in one file" violates that a lot.
>> /sys/kernel/security/ is not sysfs but securityfs.
>> Does "one-value-per-file rule" also apply to securityfs?
> It should apply. It's not so much a matter of rules and regulations.
> One needs to look at the underlying _reasons_ why those rules came
> about. We got ourselves into a sticky mess with procfs with all sorts
> of ad-hoc data presentation and input formatting. It's inconsistent,
> complex, makes tool writing harder, etc.
> So we recognised our mistakes and when sysfs (otherwise known as procfs
> V2 :)) came about we decided that sysfs files should not make the same
> mistakes.
> So, logically, that thinking should apply to all new pseudo-fs files.
> Even, in fact, ones which are in /proc!
Well, regarding memory usage, it is easy to follow "one-value-per-file rule".
But regarding policy information (which is managed as lists),
"one-value-per-file rule" is not suitable. I think none of SELinux, SMACK,
AppArmor, TOMOYO create "one pseudo file for one value".
This /sys/kernel/security/tomoyo/ interface is used by only TOMOYO's management
programs, and not by generic programs.


 \ /
  Last update: 2008-11-11 08:35    [W:0.715 / U:0.076 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site