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
25 matches
Mail list logo
