public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: cygwin@cygwin.com
Subject: Re: Extended attributes
Date: Thu, 16 Jan 2014 09:16:00 -0000	[thread overview]
Message-ID: <20140116091600.GC26205@calimero.vinschen.de> (raw)
In-Reply-To: <001701cf1281$5fc57150$1f5053f0$%fedin@samsung.com>

[-- 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 --]

  reply	other threads:[~2014-01-16  9:16 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-13 13:53 Pavel Fedin
2014-01-13 14:10 ` Corinna Vinschen
2014-01-15  6:27   ` Pavel Fedin
2014-01-15  9:15     ` Corinna Vinschen
2014-01-16  6:08       ` Pavel Fedin
2014-01-16  9:16         ` Corinna Vinschen [this message]
2014-01-16 18:52           ` Christopher Faylor
2014-01-20  5:22           ` Pavel Fedin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140116091600.GC26205@calimero.vinschen.de \
    --to=corinna-cygwin@cygwin.com \
    --cc=cygwin@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).