lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <16503.1235744837@jrobl>
Date:	Fri, 27 Feb 2009 23:27:17 +0900
From:	hooanon05@...oo.co.jp
To:	"David P. Quigley" <dpquigl@...ho.nsa.gov>
Cc:	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC 0/8] Aufs2 documents 


"David P. Quigley":
> an EOPNOTSUPP back. Considering things such as ACLs and SELinux labels
> are stored in xattrs it seems that failing a copyup on EOPNOTSUPP is a
> very reasonable thing to do.

Do you mean ... ?
- if aufs and its lower branch fs support xattr but its upper branch
  doesn't, then some of copyup will fail.
- that is user's choice.


> > Finally I am considering to make some levels to support xattr.
> > - support minimum common set of key only (if such set exists)
> >   Here "minimum common set" means a group of key which are surely
> >   supported by all filesystems. Aufs will filter-out other keys.
> > - create a new internal status flag
> >   This flag is set when the type of all branches are same. When the flag
> >   is set, aufs will handle xattr by simply redirecting.
> > - create a new aufs mount option
> >   the option will select two behaviours (above).
> 
> So I don't think this is a good way of going about it. The idea of
> having some flag which indicates just relay to the lower filesystems if
> they are all the same completely ignores that you may have several file
> systems which all support the required namespaces. One example I can

When all branch filesystems support the required xattr even if thier
filesystem-type differ, user can specify the mount option (the thrid
level above) and all xattr will be handled. When any of xattr are not
supported by the upper branch fs, then copyup will fail.
Do I make my clear, or do I misunderstand you?


> If you have more questions about this feel free to ask. I don't have
> time to actually do work in this space but I can answer whatever
> questions you have.

I am afraid I don't fully understand what you wrote.
According to linux/Documentation/Smack.txt, "xattr support is not
strictly required". But for selinux (or other security mechanism), xattr
is neccessary as you wrote.
Please tell me the url where I should know about security label or
type. Particulary "iso9660_t" type, I don't know what it is.
And do you believe the lack of supporting xattr is critical for aufs to
be merged?


J. R. Okajima
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ