[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <737394.85994.qm@web36611.mail.mud.yahoo.com>
Date: Sat, 13 Oct 2007 12:26:13 -0700 (PDT)
From: Casey Schaufler <casey@...aufler-ca.com>
To: Al Viro <viro@....linux.org.uk>,
Casey Schaufler <casey@...aufler-ca.com>
Cc: torvalds@...l.org, akpm@...l.org, linux-kernel@...r.kernel.org,
linux-security-module@...r.kernel.org
Subject: Re: [PATCH] Version 6 (2.6.23) Smack: Simplified Mandatory Access Control Kernel
--- Al Viro <viro@....linux.org.uk> wrote:
> On Fri, Oct 12, 2007 at 10:01:17PM -0700, Casey Schaufler wrote:
>
> What do you need smk_sb for? Looks like dead weight...
Reminant of an abandoned thought process. Cleaning.
> smk_read_load(): obvious seq_file candidate.
> smk_read_cipso(): ditto.
>
> What protects smk_cipso_written? BTW, its use on the read side is an
> atrocity...
>
> smk_write_doi() - WTF would NUL-terminate temp[]? You run sscanf on
> it...
> smk_write_direct() - ditto
> smk_write_ambient() - ditto
> smk_read_ambient() - who said that you won't get write between strlen()
> and simple_read_from_buffer()?
Eek. The smackfs code does look pretty crufty in the
context of seq_file, doesn't it? I will have a go at
cleaning that up some.
> smk_import_entry():
> > + for (skp = smack_known; skp != NULL; skp = skp->smk_next)
> > + if (skp->smk_known == smack)
> > + break;
> Really? With smack[] being an auto array?
Nope. What you see there is a flaw, a mistake, a bug.
And a serious memory use problem, too. Fix in test.
Thank you.
> That's from quick look through the read/write in there; I hadn't really
> looked into parsers or deeper into the guts.
Your suggestions regarding seq_file look helpful. Thank you.
Casey Schaufler
casey@...aufler-ca.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists