Hi Pavel,
On Nov 11, 2007 2:44 PM, Pavel Machek <[EMAIL PROTECTED]> wrote:
> Hi!
>
> > > A Smack Rule in an "egrep" format is:
> > >
> > > "^[:space:]*Subject[:space:]+Object[:space:]+[rwxaRWXA-]+[:space:]*\n"
>
> Perhaps you should make it space, not 'space or tab', and only allow
> lowercase per
Hi!
> > A Smack Rule in an "egrep" format is:
> >
> > "^[:space:]*Subject[:space:]+Object[:space:]+[rwxaRWXA-]+[:space:]*\n"
Perhaps you should make it space, not 'space or tab', and only allow
lowercase permissions? That way, parser will be slightly simpler, and
you'll still have a chance to us
On Nov 10, 2007 7:05 PM, Jakob Oestergaard <[EMAIL PROTECTED]> wrote:
> ...
> > I've double-checked the code for any possible off-by-one/overflow
> > errors.
> ...
>
> Two things caught my eye.
>
> ...
> > + case bol:
> > + case subject:
> > + if (*label_
...
> I've double-checked the code for any possible off-by-one/overflow
> errors.
...
Two things caught my eye.
...
> + case bol:
> + case subject:
> + if (*label_len >= SMK_MAXLEN)
> + goto out;
> + subj
> Users are used to work on characters, not on bytes.
Absolutely true - but completely missing the point.
When I open a UTF-8 file name as displayed by nautilus the kernel does
byte comparisons. The kernel doesn't care what character set is in use.
> > So you either implement "match one byte", o
On Wed, 7 Nov 2007, Adrian Bunk wrote:
>
> Users are used to work on characters, not on bytes.
Adrian, stop this idiocy. I'm not interested in listening to your
soliloqui about irrelevant stuff.
The kernel works on bytes. Deal with it. Stop whining.
You've been told several times that all t
On Tue, Nov 06, 2007 at 05:06:23PM -0800, Linus Torvalds wrote:
>
>
> On Wed, 7 Nov 2007, Adrian Bunk wrote:
> >
> > How should TOMOYO implement it's "match one character" in a pattern
> > (used to allow or deny access in a name-based MAC)?
>
> .. I think such a design is fundamentally bogus. Yo
On Wed, 7 Nov 2007, Adrian Bunk wrote:
>
> How should TOMOYO implement it's "match one character" in a pattern
> (used to allow or deny access in a name-based MAC)?
.. I think such a design is fundamentally bogus. You don't have
"characters". You have "bytes".
So you either implement "match on
Hello.
Adrian Bunk wrote:
> How should TOMOYO implement it's "match one character" in a pattern
> (used to allow or deny access in a name-based MAC)?
TOMOYO assumes that "one character" equals to "one byte"
since TOMOYO doesn't consider encoding.
According to your definition of "character" (i.e.
On Tue, Nov 06, 2007 at 04:27:19PM -0800, Linus Torvalds wrote:
>
>
> On Wed, 7 Nov 2007, Adrian Bunk wrote:
> >
> > But if you want to match "one character" (like TOMOYO does) or want to
> > check for printable characters except space (like Smack does) you must
> > know whether the byte strin
On Wed, 7 Nov 2007, Adrian Bunk wrote:
>
> But if you want to match "one character" (like TOMOYO does) or want to
> check for printable characters except space (like Smack does) you must
> know whether the byte string 0xC3 0xA0 is the character à or a sequence
> of two characters with the sec
On Tue, Nov 06, 2007 at 03:08:08PM -0800, Linus Torvalds wrote:
>
>
> On Wed, 7 Nov 2007, Adrian Bunk wrote:
> >
> > You were the one who suggested to _parse_ strings in the kernel.
>
> So?
>
> We do that for lots of things.
>
> What do you think a filename is? And yes, we parse it. Things li
On Wed, 7 Nov 2007, Adrian Bunk wrote:
>
> You were the one who suggested to _parse_ strings in the kernel.
So?
We do that for lots of things.
What do you think a filename is? And yes, we parse it. Things like '/' and
'.' and '..' have magic meaning.
You don't need to bring up idiotic thing
On Tue, Nov 06, 2007 at 07:39:09AM -0800, Linus Torvalds wrote:
>
>
> On Tue, 6 Nov 2007, Adrian Bunk wrote:
> >
> > How do we get the information about the character encoding of the string
> > to be parsed into the kernel?
>
> I really would expect that kernel strings don't have an encoding.
On Wed, Nov 07, 2007 at 12:27:04AM +0900, Tetsuo Handa wrote:
> Hello.
>
> Adrian Bunk wrote:
> > The problem is that your code matches one byte, not one character.
> >
> > More or less all userspace programs handle multi-byte UTF-8 characters
> > just fine without bothering the user with the fa
On Tue, 6 Nov 2007, Kyle Moffett wrote:
>
> Personally I think that isspace() accepting character 0xA0 is a bug
I think I agree with you. As far as the kernel is concerned, "isspace()"
should just accept the obvious spaces (hardspace, tab, newline), and
*perhaps* the VT/FF kind of things.
Yo
On Tue, 6 Nov 2007, Adrian Bunk wrote:
>
> How do we get the information about the character encoding of the string
> to be parsed into the kernel?
I really would expect that kernel strings don't have an encoding. They're
just C strings: a NUL-terminated stream of bytes.
Linu
Hello.
Adrian Bunk wrote:
> The problem is that your code matches one byte, not one character.
>
> More or less all userspace programs handle multi-byte UTF-8 characters
> just fine without bothering the user with the fact whether a character
> consists of one or more bytes.
I understood what y
On Tue, Nov 06, 2007 at 11:32:15PM +0900, Tetsuo Handa wrote:
> Hello.
>
> Adrian Bunk wrote:
> > And \* is not a replacement for \?. It's quite common to have both ways
> > to express "one character" and to express "at least one character", and
> > both have their use cases and will get used if
Hello.
Adrian Bunk wrote:
> And \* is not a replacement for \?. It's quite common to have both ways
> to express "one character" and to express "at least one character", and
> both have their use cases and will get used if available.
You can use \? to represent "one character" and
\?\* to repres
On 11/6/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> On Tue, Nov 06, 2007 at 04:05:13PM +0200, Ahmed S. Darwish wrote:
> >
> > Great, To summarize the discussion. Will there be a problem in
> > accepting ASCII and the UTF-8 ASCII _subset_ _only_ and return
> > -EINVAL for all other cases/ecnodings
On Tue, Nov 06, 2007 at 04:05:13PM +0200, Ahmed S. Darwish wrote:
> On Tue, Nov 06, 2007 at 02:34:46PM +0100, Adrian Bunk wrote:
> > On Tue, Nov 06, 2007 at 07:49:26AM -0500, Kyle Moffett wrote:
> > > On Nov 06, 2007, at 07:23:36, Ahmed S. Darwish wrote:
> > >> On 11/6/07, Adrian Bunk <[EMAIL PROTE
On Tue, Nov 06, 2007 at 02:34:46PM +0100, Adrian Bunk wrote:
> On Tue, Nov 06, 2007 at 07:49:26AM -0500, Kyle Moffett wrote:
> > On Nov 06, 2007, at 07:23:36, Ahmed S. Darwish wrote:
> >> On 11/6/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> >>> On Tue, Nov 06, 2007 at 01:34:05PM +0200, Ahmed S. Dar
On Tue, Nov 06, 2007 at 09:27:00PM +0900, Tetsuo Handa wrote:
> Hello.
>
> Adrian Bunk wrote:
> > You have a "\?" pattern which is defined as "1 byte character other
> > than '/'".
> Don't worry. The "\?" pattern is for temporary files with /tmp/prefixXX
> pattern.
> /tmp/prefixXX is repr
On Tue, Nov 06, 2007 at 07:49:26AM -0500, Kyle Moffett wrote:
> On Nov 06, 2007, at 07:23:36, Ahmed S. Darwish wrote:
>> On 11/6/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
>>> On Tue, Nov 06, 2007 at 01:34:05PM +0200, Ahmed S. Darwish wrote:
As far as I understand the problem now, isspace() ac
On Nov 06, 2007, at 07:23:36, Ahmed S. Darwish wrote:
On 11/6/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
On Tue, Nov 06, 2007 at 01:34:05PM +0200, Ahmed S. Darwish wrote:
As far as I understand the problem now, isspace() accepts the
0xa0 character which might collide with some of UTF-8 encoded
Hello.
Adrian Bunk wrote:
> You have a "\?" pattern which is defined as "1 byte character other
> than '/'".
Don't worry. The "\?" pattern is for temporary files with /tmp/prefixXX
pattern.
/tmp/prefixXX is represented as /tmp/prefix\?\?\?\?\?\? in TOMOYO Linux's
syntax.
> The user usua
On 11/6/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> On Tue, Nov 06, 2007 at 01:34:05PM +0200, Ahmed S. Darwish wrote:
> > Hi,
> >
> > On Tue, Nov 06, 2007 at 09:56:51AM +0100, Adrian Bunk wrote:
> > > On Tue, Nov 06, 2007 at 03:26:12AM -0500, Kyle Moffett wrote:
> > > > On Nov 06, 2007, at 01:33:0
On Tue, Nov 06, 2007 at 01:34:05PM +0200, Ahmed S. Darwish wrote:
> Hi,
>
> On Tue, Nov 06, 2007 at 09:56:51AM +0100, Adrian Bunk wrote:
> > On Tue, Nov 06, 2007 at 03:26:12AM -0500, Kyle Moffett wrote:
> > > On Nov 06, 2007, at 01:33:05, Adrian Bunk wrote:
> > >> Can you limit this to 7bit ASCII
Hi,
On Tue, Nov 06, 2007 at 09:56:51AM +0100, Adrian Bunk wrote:
> On Tue, Nov 06, 2007 at 03:26:12AM -0500, Kyle Moffett wrote:
> > On Nov 06, 2007, at 01:33:05, Adrian Bunk wrote:
> >> Can you limit this to 7bit ASCII and use isascii() somewhere?
> >>
> >> Otherwise I'd expect funny things to ha
> The documentations says:
> "Smack labels cannot contain unprintable characters or the "/" (slash)
> character."
>
> What you propose might contain unprintable characters, and it might even
> be invalid UTF-8.
Just like filenames then. I haven't noticed the vfs explode as a result
Alan
-
To
On Tue, Nov 06, 2007 at 06:56:43AM +0900, Tetsuo Handa wrote:
>
> Linus Torvalds wrote:
> > I personally think string parsers are *much* better than the alternatives
> > (which basically boil down to nasty binary interfaces)
> Me too.
>
> > Binary structures and ioctl's are *much* worse. They ar
On Tue, Nov 06, 2007 at 03:26:12AM -0500, Kyle Moffett wrote:
> On Nov 06, 2007, at 01:33:05, Adrian Bunk wrote:
>> Can you limit this to 7bit ASCII and use isascii() somewhere?
>>
>> Otherwise I'd expect funny things to happen when you e.g. use isspace() on
>> the UTF-8 encoded character à.
>
> A
On Nov 06, 2007, at 01:33:05, Adrian Bunk wrote:
Can you limit this to 7bit ASCII and use isascii() somewhere?
Otherwise I'd expect funny things to happen when you e.g. use
isspace() on the UTF-8 encoded character à.
Actually, you don't need to. You tell them it expects UTF-8 encoded
stri
On Mon, Nov 05, 2007 at 08:21:04AM -0800, Linus Torvalds wrote:
>
>
> On Mon, 5 Nov 2007, Ahmed S. Darwish wrote:
>
> > On Sun, Nov 04, 2007 at 12:28:48PM +, Pavel Machek wrote:
> > >
> > > Can we avoid string parsers in the kernel?
> > >
> >
> > Ok, Could someone suggest a better idea pl
On Sat, Nov 03, 2007 at 06:43:06PM +0200, Ahmed S. Darwish wrote:
> On Fri, Nov 02, 2007 at 01:50:55PM -0700, Casey Schaufler wrote:
> >
> > Still to come:
> >
> > - Final cleanup of smack_load_write and smack_cipso_write.
>
> Hi All,
>
> After agreeing with Casey on the "load" input grammar
On 11/5/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>
> On Mon, 5 Nov 2007, Ahmed S. Darwish wrote:
>
> > On Sun, Nov 04, 2007 at 12:28:48PM +, Pavel Machek wrote:
> > >
> > > Can we avoid string parsers in the kernel?
> > >
> >
> > Ok, Could someone suggest a better idea please ?.
>
> I pe
Linus Torvalds wrote:
> I personally think string parsers are *much* better than the alternatives
> (which basically boil down to nasty binary interfaces)
Me too.
> Binary structures and ioctl's are *much* worse. They are totally
> undebuggable with generic tools (think "echo" or "strace"), and
On Mon, 5 Nov 2007, Ahmed S. Darwish wrote:
> On Sun, Nov 04, 2007 at 12:28:48PM +, Pavel Machek wrote:
> >
> > Can we avoid string parsers in the kernel?
> >
>
> Ok, Could someone suggest a better idea please ?.
I personally think string parsers are *much* better than the alternatives
On Sun, Nov 04, 2007 at 12:28:48PM +, Pavel Machek wrote:
> Hi!
>
> > > Still to come:
> > >
> > > - Final cleanup of smack_load_write and smack_cipso_write.
> >
> > Hi All,
> >
> > After agreeing with Casey on the "load" input grammar yesterday, here's
> > the final grammar and its parse
On Sat, Nov 03, 2007 at 06:43:06PM +0200, Ahmed S. Darwish wrote:
> On Fri, Nov 02, 2007 at 01:50:55PM -0700, Casey Schaufler wrote:
> >
> > Still to come:
> >
> > - Final cleanup of smack_load_write and smack_cipso_write.
>
> Hi All,
>
> After agreeing with Casey on the "load" input grammar
On 11/3/07, Ahmed S. Darwish <[EMAIL PROTECTED]> wrote:
> static int smk_open_load(struct inode *inode, struct file *file)
> {
> - return seq_open(file, &load_seq_ops);
> + if ((file->f_flags & O_ACCMODE) == O_RDONLY)
> + return seq_open(file, &load_seq_ops);
> +
> +
--- "Ahmed S. Darwish" <[EMAIL PROTECTED]> wrote:
> On 11/4/07, Pavel Machek <[EMAIL PROTECTED]> wrote:
> > Hi!
> >
> > > > Still to come:
> > > >
> > > > - Final cleanup of smack_load_write and smack_cipso_write.
> > >
> > > Hi All,
> > >
> > > After agreeing with Casey on the "load" input gra
On 11/4/07, Pavel Machek <[EMAIL PROTECTED]> wrote:
> Hi!
>
> > > Still to come:
> > >
> > > - Final cleanup of smack_load_write and smack_cipso_write.
> >
> > Hi All,
> >
> > After agreeing with Casey on the "load" input grammar yesterday, here's
> > the final grammar and its parser (which needs
Hi!
> > Still to come:
> >
> > - Final cleanup of smack_load_write and smack_cipso_write.
>
> Hi All,
>
> After agreeing with Casey on the "load" input grammar yesterday, here's
> the final grammar and its parser (which needs more testing):
>
> A Smack Rule in an "egrep" format is:
>
> "^[:
On 11/3/07, Kyle Moffett <[EMAIL PROTECTED]> wrote:
> On Nov 03, 2007, at 12:43:06, Ahmed S. Darwish wrote:
> > Bashv3 builtin "echo" behaves very strangely to -EINVAL. It sends
> > all the buffers that causes -EINVAL again in subsequent echo
> > invocations.
> >
> > i.e.
> > echo "Invalid Rule" >
On Nov 03, 2007, at 12:43:06, Ahmed S. Darwish wrote:
Bashv3 builtin "echo" behaves very strangely to -EINVAL. It sends
all the buffers that causes -EINVAL again in subsequent echo
invocations.
i.e.
echo "Invalid Rule" > /smack/load # -EINVAL returned
echo "Valid Rule" > /smack/load
In sec
On Fri, Nov 02, 2007 at 01:50:55PM -0700, Casey Schaufler wrote:
>
> Still to come:
>
> - Final cleanup of smack_load_write and smack_cipso_write.
Hi All,
After agreeing with Casey on the "load" input grammar yesterday, here's
the final grammar and its parser (which needs more testing):
A Sm
48 matches
Mail list logo
