Extended attributes

Extended attributes

[Pavel Fedin]

 Hello!

 Is there any support for xattrs ? I sometimes work with SquashFS images
which make use of them (like security.capability) and i'd like to be able to
store them along files.
If not implemented, can this be somehow fulfilled ? For example, we could
store them in a dedicated NTFS stream.

Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia




--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Extended attributes

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 717 bytes --]

On Jan 13 17:53, Pavel Fedin wrote:
>  Hello!
> 
>  Is there any support for xattrs ? I sometimes work with SquashFS images
> which make use of them (like security.capability) and i'd like to be able to
> store them along files.
> If not implemented, can this be somehow fulfilled ? For example, we could
> store them in a dedicated NTFS stream.

"user." xattrs are supported, but no others.  This is partially to have
smooth support of  xattrs when using Samba shares.  See the attr package
and the getxattr, etc. calls in Cygwin's ntea.cc.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

RE: Extended attributes

[Pavel Fedin]

 Hello!

> "user." xattrs are supported, but no others.  This is partially to have
> smooth support of  xattrs when using Samba shares.  See the attr
> package and the getxattr, etc. calls in Cygwin's ntea.cc.

 Yes, i have checked that.
 What do you think about adding other possible namespaces (system, security, and... don't remember the 3rd one) ? So that when manipulating UNIX archives etc these attributes could be kept along with files ? At least we have one use case now.

 P.S. Sorry if the message duplicates. I have tried to send it from home, but for some reason it got swallowed.

Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia



--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Extended attributes

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1102 bytes --]

On Jan 15 10:27, Pavel Fedin wrote:
>  Hello!
> 
> > "user." xattrs are supported, but no others.  This is partially to have
> > smooth support of  xattrs when using Samba shares.  See the attr
> > package and the getxattr, etc. calls in Cygwin's ntea.cc.
> 
>  Yes, i have checked that.
>  What do you think about adding other possible namespaces (system,
>  security, and... don't remember the 3rd one) ? So that when
>  manipulating UNIX archives etc these attributes could be kept along
>  with files ? At least we have one use case now.

That doesn't make sense.  Extended attributes as implemented by Windows
are user attributes, not system attributes.  The non-user attributes
on Linux have a very special meaning to the kernel and/or are restricted
to privileged users only.  Their functionality is already provided by
other OS functions (as for system.posix_acl_access) or not at all (as
for security.selinux).


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

RE: Extended attributes

[Pavel Fedin]

 Hello!

> >  What do you think about adding other possible namespaces (system,
> > security, and... don't remember the 3rd one) ? So that when
> > manipulating UNIX archives etc these attributes could be kept along
> > with files ? At least we have one use case now.
> 
> That doesn't make sense.  Extended attributes as implemented by Windows
> are user attributes, not system attributes.  The non-user attributes on
> Linux have a very special meaning to the kernel and/or are restricted
> to privileged users only.  Their functionality is already provided by
> other OS functions (as for system.posix_acl_access) or not at all (as
> for security.selinux).

 I know they have special meaning. At the other hand, if we allow them, we will allow to store them on a filesystem. Wouldn't it be nice ? This is useful at least for SquashFS image preparation.
 I guess for similar reasons we have support e. g. for device nodes (/dev) with their major/minor numbers. They are also ignored by Cygwin, and just stored on the filesystem (or do i miss something ?).

Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia



--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Extended attributes

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2617 bytes --]

On Jan 16 10:08, Pavel Fedin wrote:
>  Hello!
> 
> > >  What do you think about adding other possible namespaces (system,
> > > security, and... don't remember the 3rd one) ? So that when
> > > manipulating UNIX archives etc these attributes could be kept along
> > > with files ? At least we have one use case now.
> > 
> > That doesn't make sense.  Extended attributes as implemented by Windows
> > are user attributes, not system attributes.  The non-user attributes on
> > Linux have a very special meaning to the kernel and/or are restricted
> > to privileged users only.  Their functionality is already provided by
> > other OS functions (as for system.posix_acl_access) or not at all (as
> > for security.selinux).
> 
>  I know they have special meaning. At the other hand, if we allow
>  them, we will allow to store them on a filesystem. Wouldn't it be
>  nice ? This is useful at least for SquashFS image preparation.
>  I guess for similar reasons we have support e. g. for device nodes
>  (/dev) with their major/minor numbers. They are also ignored by
>  Cygwin, and just stored on the filesystem (or do i miss something ?).

Yes, the history.  The device nodes were a start to implement actual
loadable device handler code (application level, not actual device
drivers), but for some reason it was never fully implemented.

I'm really not inclined to add this.  As it is, the NTFS xattr are
always treated as user attributes.  An NTFS attr "foo.bar" is returned
as "user.foo.bar" and when writing, a "user.foo.bar" is written as
"foo.bar".  Adding other attribute types requires to add some special
casing and parsing code to differ user attributes from other attributes
without breaking backward compatibility.

Also, it will never work correctly on a Samba share, because Samba will
always treat the incoming attribute as above.  So, if you write an
attribute "trusted.md5sum" on a samba share, it will actually be
converted to "user.trusted.md5sum" by Samba.

Another point is stuff like system.posix_acl_access.  It's the
underlying implementation of POSIX ACLs on Linux, so an application
with sufficient access rights could read and write the content directly,
rather than using the system calls.  But the surprise from the
application point of view is, the "system.posix_acl_access" xattrs will
have no effect in terms of permissions.

Having said that, http://cygwin.com/acronyms/#PTC.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Extended attributes

[Christopher Faylor]

On Thu, Jan 16, 2014 at 10:16:00AM +0100, Corinna Vinschen wrote:
>On Jan 16 10:08, Pavel Fedin wrote:
>>  Hello!
>> 
>> > >  What do you think about adding other possible namespaces (system,
>> > > security, and... don't remember the 3rd one) ? So that when
>> > > manipulating UNIX archives etc these attributes could be kept along
>> > > with files ? At least we have one use case now.
>> > 
>> > That doesn't make sense.  Extended attributes as implemented by Windows
>> > are user attributes, not system attributes.  The non-user attributes on
>> > Linux have a very special meaning to the kernel and/or are restricted
>> > to privileged users only.  Their functionality is already provided by
>> > other OS functions (as for system.posix_acl_access) or not at all (as
>> > for security.selinux).
>> 
>>  I know they have special meaning. At the other hand, if we allow
>>  them, we will allow to store them on a filesystem. Wouldn't it be
>>  nice ? This is useful at least for SquashFS image preparation.
>>  I guess for similar reasons we have support e. g. for device nodes
>>  (/dev) with their major/minor numbers. They are also ignored by
>>  Cygwin, and just stored on the filesystem (or do i miss something ?).
>
>Yes, the history.  The device nodes were a start to implement actual
>loadable device handler code (application level, not actual device
>drivers), but for some reason it was never fully implemented.

If you're talking about the ability to create a device file anywhere
that was something that I did.  It wasn't to implement loadable device
handlers but just so that we could eventually have a real /dev populated
with device files.  However, we have since gone the route of creating a
pseudo-filesystem /dev so that's no longer necessary.

I also did this to allow the creation of fifos anywhere so that's still
a valid use case.  And, actually, creating a device node anywhere is
certainly something that you need to be able to do if you want to claim
Linux-like functionality.

Device nodes are not (or are not supposed to be) "ignored by Cygwin".

cgf

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

RE: Extended attributes

[Pavel Fedin]

 Hello!

> I'm really not inclined to add this.  As it is, the NTFS xattr are
> always treated as user attributes.  An NTFS attr "foo.bar" is returned
> as "user.foo.bar" and when writing, a "user.foo.bar" is written as
> "foo.bar".  Adding other attribute types requires to add some special
> casing and parsing code to differ user attributes from other attributes
> without breaking backward compatibility.
> 
> Also, it will never work correctly on a Samba share, because Samba will
> always treat the incoming attribute as above.  So, if you write an
> attribute "trusted.md5sum" on a samba share, it will actually be
> converted to "user.trusted.md5sum" by Samba.

 Sorry for late reply, too busy at work now... The same about NFS-related packages - no time ATM to make them... :(
 You know, i got your point, and perhaps this can be rethought. Perhaps this can be done on SquashFS side. For example, we could tell it to store 'security.foo' attribute as 'user.squashfs.security.foo'. This could be also useful on Linux, because in this case you don't have to be root any more to be able to prepare a rootfs for your embedded device.
 I think i'll consider that after i finish up with NFS.

Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia



--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple