On Mon, Feb 13, 2012 at 11:42:49AM +0100, Manuel Bouyer wrote:
> On Mon, Feb 13, 2012 at 10:37:25AM +, Emmanuel Dreyfus wrote:
> > On Mon, Feb 13, 2012 at 11:27:29AM +0100, Manuel Bouyer wrote:
> > > But then, if you see USER "foo.bar" in the filesystem, you don't know
> > > if it should be map
On Mon, Feb 06, 2012 at 05:04:45PM +, David Holland wrote:
> On Mon, Feb 06, 2012 at 09:51:19AM +, Emmanuel Dreyfus wrote:
> > Here is public disuccsion about extended attributs namespaces, following
> > a private request from yamt@
>
> Which of the two models does OS X use?
OS X doesn'
On Mon, Feb 13, 2012 at 11:42:49AM +0100, Manuel Bouyer wrote:
> And what happens if you write "baz.foo.bar" ? You could just error out in
> this case.
You are right. If the purpose of -o stripxattr is to let us use a disk from
FreeBSD without damages, then the option should make it impossible to
On Mon, Feb 13, 2012 at 10:37:25AM +, Emmanuel Dreyfus wrote:
> On Mon, Feb 13, 2012 at 11:27:29AM +0100, Manuel Bouyer wrote:
> > But then, if you see USER "foo.bar" in the filesystem, you don't know
> > if it should be mapped to user.foo.bar or foo.bar.
> > I don't think this can work.
>
> I
On Mon, Feb 13, 2012 at 11:27:29AM +0100, Manuel Bouyer wrote:
> But then, if you see USER "foo.bar" in the filesystem, you don't know
> if it should be mapped to user.foo.bar or foo.bar.
> I don't think this can work.
If the disk is from FreeBSD, you mount with -o stripxattr. When
you read it, U
On Fri, Feb 10, 2012 at 02:01:58PM +0100, Emmanuel Dreyfus wrote:
> [...]
> I think we just need a mount option: -o -stripxattr
> It would do this mapping:
> "system.foo" <-> SYSTEM "foo"
> "trusted.foo" <-> SYSTEM "trusted.foo"
> "security.foo" <-> SYSTEM "security.foo"
>
hi,
> The question is: do we strip/add the string namespace when
> storing/reading the values in the filesystem.
>
> For native use, I think we do not want to strip, as it is simplier. The
i agree.
> problem arise when mounting a disk from FreeBSD. Here when we ask to
> store "user.foo", we mea
Alan Barrett wrote:
> >how about the following mapping?
> >
> > xattr name string <-> ufs on-disk
> >
> > "system.foo" <-> SYSTEM "foo"
> > "others.bar" <-> USER "others.bar"
>
> Looks reasonable, but then which of the following?
>
> a)"user.user.baz" <-> USER "user.b
On Fri, 10 Feb 2012, YAMAMOTO Takashi wrote:
how about the following mapping?
xattr name string <-> ufs on-disk
"system.foo" <-> SYSTEM "foo"
"others.bar" <-> USER "others.bar"
Looks reasonable, but then which of the following?
a) "user.user.baz" <-> U
hi,
> Manuel Bouyer wrote:
>
>> I'm not sure you can even read them: on freebsd "user.foo.bar" will be stored
>> as name "foo.bar" in (integer) namespace user. When we'll read it we'll
>> find foo in (integer) namespace user but we don't know which namespace
>> it really belongs to (as we store
On Fri, Feb 10, 2012 at 09:37:30AM +, YAMAMOTO Takashi wrote:
> > On Mon, Feb 06, 2012 at 09:51:19AM +, Emmanuel Dreyfus wrote:
> > > Here is public disuccsion about extended attributs namespaces, following
> > > a private request from yamt@
> >
> > Which of the two models does OS X
> On Mon, Feb 06, 2012 at 09:51:19AM +, Emmanuel Dreyfus wrote:
> > Here is public disuccsion about extended attributs namespaces, following
> > a private request from yamt@
>
> Which of the two models does OS X use?
their api is similar to linux.
i don't know their namespace semantics, tho
> One thing that I'm wondering: what are the character constraints on
> those class names in the Linux API?
> The reason is that if UTF8 is allowed, it'd be possible for two names
> to show as an equivalent representation to humans, while they'd be
> different for the system, [...]
Only if userla
Matthew Mondor wrote:
> One thing that I'm wondering: what are the character constraints on
> those class names in the Linux API?
As I understand, the kernel just uses C strings. Encoding is userland's
tools business.
> For performance and security, integers make more sense to me than
> string
On Mon, 6 Feb 2012 09:51:19 +
Emmanuel Dreyfus wrote:
> We ahve two extended attributes API in tree: one from FreeBSD and one from
> Linux. We are about to toss the FreeBSD one in favor of the Linux one.
> That is easy now since we never had working extended attributes in a
> release.
One
Manuel Bouyer wrote:
> I'm not sure you can even read them: on freebsd "user.foo.bar" will be stored
> as name "foo.bar" in (integer) namespace user. When we'll read it we'll
> find foo in (integer) namespace user but we don't know which namespace
> it really belongs to (as we store the namespace
On Mon, Feb 06, 2012 at 05:00:05PM +, Emmanuel Dreyfus wrote:
> On Mon, Feb 06, 2012 at 05:53:09PM +0100, Manuel Bouyer wrote:
> > But if you want to have system.foo distinct from security.foo, you have
> > to duplicate the namespace in the name itself, right ?
>
> Yes, but if we want to tend
On Mon, Feb 06, 2012 at 09:51:19AM +, Emmanuel Dreyfus wrote:
> Here is public disuccsion about extended attributs namespaces, following
> a private request from yamt@
Which of the two models does OS X use?
--
David A. Holland
dholl...@netbsd.org
On Mon, Feb 06, 2012 at 05:53:09PM +0100, Manuel Bouyer wrote:
> But if you want to have system.foo distinct from security.foo, you have
> to duplicate the namespace in the name itself, right ?
Yes, but if we want to tend forward the Linux API, this is the way
to go. You cannot add abitrary user
On Mon, Feb 06, 2012 at 10:34:54AM -0600, Eric Haszlakiewicz wrote:
> setextattr system md5 `md5 -q /boot/kernel/kernel` /boot/kernel/kernel
Note that the Linux style is already supported:
setextattr system.md5 `md5 -q /boot/kernel/kernel` /boot/kernel/kernel
I recall implementing it last sum
On Mon, Feb 06, 2012 at 04:47:35PM +, Emmanuel Dreyfus wrote:
> On Mon, Feb 06, 2012 at 05:43:10PM +0100, Manuel Bouyer wrote:
> > note that the ffsv2 extended attribute on-disk format uses an int as
> > namespaces (just like the API). Nothing unworkable here, but it may
> > be tricky if we wan
On Mon, Feb 06, 2012 at 05:43:10PM +0100, Manuel Bouyer wrote:
> note that the ffsv2 extended attribute on-disk format uses an int as
> namespaces (just like the API). Nothing unworkable here, but it may
> be tricky if we want to be compatible with FreeBSD ...
We can just test the namespace in str
On Mon, Feb 06, 2012 at 09:51:19AM +, Emmanuel Dreyfus wrote:
> Here is public disuccsion about extended attributs namespaces, following
> a private request from yamt@
>
> We ahve two extended attributes API in tree: one from FreeBSD and one from
> Linux. We are about to toss the FreeBSD one
On Mon, Feb 06, 2012 at 04:23:34PM +, Eduardo Horvath wrote:
> On Mon, 6 Feb 2012, Emmanuel Dreyfus wrote:
> > We ahve two extended attributes API in tree: one from FreeBSD and one from
> > Linux. We are about to toss the FreeBSD one in favor of the Linux one.
> > That is easy now since we ne
On Mon, 6 Feb 2012, Emmanuel Dreyfus wrote:
> Here is public disuccsion about extended attributs namespaces, following
> a private request from yamt@
>
> We ahve two extended attributes API in tree: one from FreeBSD and one from
> Linux. We are about to toss the FreeBSD one in favor of the Linux
Here is public disuccsion about extended attributs namespaces, following
a private request from yamt@
We ahve two extended attributes API in tree: one from FreeBSD and one from
Linux. We are about to toss the FreeBSD one in favor of the Linux one.
That is easy now since we never had working exte
26 matches
Mail list logo
