Eric Lee / smarc-fsl-linux-kernel

06 Nov, 2019

1 commit

  • 3484eba91   FROMLIST: Add flags option to get xattr method paired to __vfs_getxattr ... Browse Code »

    Add a flag option to get xattr method that could have a bit flag of
    XATTR_NOSECURITY passed to it. XATTR_NOSECURITY is generally then
    set in the __vfs_getxattr path when called by security
    infrastructure.

    This handles the case of a union filesystem driver that is being
    requested by the security layer to report back the xattr data.

    For the use case where access is to be blocked by the security layer.

    The path then could be security(dentry) ->
    __vfs_getxattr(dentry...XATTR_NOSECURITY) ->
    handler->get(dentry...XATTR_NOSECURITY) ->
    __vfs_getxattr(lower_dentry...XATTR_NOSECURITY) ->
    lower_handler->get(lower_dentry...XATTR_NOSECURITY)
    which would report back through the chain data and success as
    expected, the logging security layer at the top would have the
    data to determine the access permissions and report back the target
    context that was blocked.

    Without the get handler flag, the path on a union filesystem would be
    the errant security(dentry) -> __vfs_getxattr(dentry) ->
    handler->get(dentry) -> vfs_getxattr(lower_dentry) -> nested ->
    security(lower_dentry, log off) -> lower_handler->get(lower_dentry)
    which would report back through the chain no data, and -EACCES.

    For selinux for both cases, this would translate to a correctly
    determined blocked access. In the first case with this change a correct avc
    log would be reported, in the second legacy case an incorrect avc log
    would be reported against an uninitialized u:object_r:unlabeled:s0
    context making the logs cosmetically useless for audit2allow.

    This patch series is inert and is the wide-spread addition of the
    flags option for xattr functions, and a replacement of __vfs_getxattr
    with __vfs_getxattr(...XATTR_NOSECURITY).

    Signed-off-by: Mark Salyzyn
    Reviewed-by: Jan Kara
    Acked-by: Jan Kara
    Acked-by: Jeff Layton
    Acked-by: David Sterba
    Acked-by: Darrick J. Wong
    Acked-by: Mike Marshall
    Cc: Stephen Smalley
    Cc: linux-kernel@vger.kernel.org
    Cc: kernel-team@android.com
    Cc: linux-security-module@vger.kernel.org

    (cherry picked from (rejected from archive because of too many recipients))
    Signed-off-by: Mark Salyzyn
    Bug: 133515582
    Bug: 136124883
    Bug: 129319403
    Change-Id: Iabbb8771939d5f66667a26bb23ddf4c562c349a1

    Mark Salyzyn
     

23 Aug, 2018

1 commit

  • f168d9fd6   hfsplus: drop ACL support ... Browse Code »

    The HFS+ Access Control Lists have not worked at all for the past five
    years, and nobody seems to have noticed. Besides, POSIX draft ACLs are
    not compatible with MacOS. Drop the feature entirely.

    Link: http://lkml.kernel.org/r/20180714190608.wtnmmtjqeyladkut@eaf
    Signed-off-by: Ernesto A. Fernández
    Acked-by: Christoph Hellwig
    Cc: Viacheslav Dubeyko
    Cc: Jan Kara
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Ernesto A. Fernández
     

02 Nov, 2017

1 commit

  • b24413180   License cleanup: add SPDX GPL-2.0 license identifier to files with no license ... Browse Code »

    Many source files in the tree are missing licensing information, which
    makes it harder for compliance tools to determine the correct license.

    By default all files without license information are under the default
    license of the kernel, which is GPL version 2.

    Update the files which contain no license information with the 'GPL-2.0'
    SPDX license identifier. The SPDX identifier is a legally binding
    shorthand, which can be used instead of the full boiler plate text.

    This patch is based on work done by Thomas Gleixner and Kate Stewart and
    Philippe Ombredanne.

    How this work was done:

    Patches were generated and checked against linux-4.14-rc6 for a subset of
    the use cases:
    - file had no licensing information it it.
    - file was a */uapi/* one with no licensing information in it,
    - file was a */uapi/* one with existing licensing information,

    Further patches will be generated in subsequent months to fix up cases
    where non-standard license headers were used, and references to license
    had to be inferred by heuristics based on keywords.

    The analysis to determine which SPDX License Identifier to be applied to
    a file was done in a spreadsheet of side by side results from of the
    output of two independent scanners (ScanCode & Windriver) producing SPDX
    tag:value files created by Philippe Ombredanne. Philippe prepared the
    base worksheet, and did an initial spot review of a few 1000 files.

    The 4.13 kernel was the starting point of the analysis with 60,537 files
    assessed. Kate Stewart did a file by file comparison of the scanner
    results in the spreadsheet to determine which SPDX license identifier(s)
    to be applied to the file. She confirmed any determination that was not
    immediately clear with lawyers working with the Linux Foundation.

    Criteria used to select files for SPDX license identifier tagging was:
    - Files considered eligible had to be source code files.
    - Make and config files were included as candidates if they contained >5
    lines of source
    - File already had some variant of a license header in it (even if
    Reviewed-by: Philippe Ombredanne
    Reviewed-by: Thomas Gleixner
    Signed-off-by: Greg Kroah-Hartman

    Greg Kroah-Hartman
     

28 May, 2016

1 commit

11 Apr, 2016

1 commit

14 Nov, 2015

2 commits

  • d9a82a040   xattr handlers: Pass handler to operations instead of flags ... Browse Code »

    The xattr_handler operations are currently all passed a file system
    specific flags value which the operations can use to disambiguate between
    different handlers; some file systems use that to distinguish the xattr
    namespace, for example. In some oprations, it would be useful to also have
    access to the handler prefix. To allow that, pass a pointer to the handler
    to operations instead of the flags value alone.

    Signed-off-by: Andreas Gruenbacher
    Reviewed-by: Christoph Hellwig
    Signed-off-by: Al Viro

    Andreas Gruenbacher
     
  • e282fb7f3   hfsplus: Remove unused xattr handler list operations ... Browse Code »

    The list operations can never be called; they are even documented to be
    unused.

    Signed-off-by: Andreas Gruenbacher
    Reviewed-by: Christoph Hellwig
    Signed-off-by: Al Viro

    Andreas Gruenbacher
     

17 Apr, 2015

2 commits

07 Jun, 2014

1 commit

  • bf29e886b   hfsplus: correct usage of HFSPLUS_ATTR_MAX_STRLEN for non-English attributes ... Browse Code »

    HFSPLUS_ATTR_MAX_STRLEN (=127) is the limit of attribute names for the
    number of unicode character (UTF-16BE) storable in the HFS+ file system.
    Almost all the current usage of it is wrong, in relation to NLS to
    on-disk conversion.

    Except for one use calling hfsplus_asc2uni (which should stay the same)
    and its uses in calling hfsplus_uni2asc (which was corrected in the
    earlier patch in this series concerning usage of hfsplus_uni2asc), all
    the other uses are of the forms:

    - char buffer[size]

    - bound check: "if (namespace_adjusted_input_length > size) return failure;"

    Conversion between on-disk unicode representation and NLS char strings
    (in whichever direction) always needs to accommodate the worst-case NLS
    conversion, so all char buffers of that size need to have a
    NLS_MAX_CHARSET_SIZE x .

    The bound checks are all wrong, since they compare nls_length derived
    from strlen() to a unicode length limit.

    It turns out that all the bound-checks do is to protect
    hfsplus_asc2uni(), which can fail if the input is too large.

    There is only one usage of it as far as attributes are concerned, in
    hfsplus_attr_build_key(). It is in turn used by hfsplus_find_attr(),
    hfsplus_create_attr(), hfsplus_delete_attr(). Thus making sure that
    errors from hfsplus_asc2uni() is caught in hfsplus_attr_build_key() and
    propagated is sufficient to replace all the bound checks.

    Unpropagated errors from hfsplus_asc2uni() in the file catalog code was
    addressed recently in an independent patch "hfsplus: fix longname
    handling" by Sougata Santra.

    Before this patch, trying to set a 55 CJK character (in a UTF-8 locale,
    > 127/3=42) attribute plus user prefix fails with:

    $ setfattr -n user.`cat testing-string` -v `cat testing-string` \
    testing-string
    setfattr: testing-string: Operation not supported

    and retrieving a stored long attributes is particular ugly(!):

    find /mnt/* -type f -exec getfattr -d {} \;
    getfattr: /mnt/testing-string: Input/output error

    with console log:
    [268008.389781] hfsplus: unicode conversion failed

    After the patch, both of the above works.

    FYI, the test attribute string is prepared with:

    echo -e -n \
    "\xe9\x80\x99\xe6\x98\xaf\xe4\xb8\x80\xe5\x80\x8b\xe9\x9d\x9e\xe5" \
    "\xb8\xb8\xe6\xbc\xab\xe9\x95\xb7\xe8\x80\x8c\xe6\xa5\xb5\xe5\x85" \
    "\xb6\xe4\xb9\x8f\xe5\x91\xb3\xe5\x92\x8c\xe7\x9b\xb8\xe7\x95\xb6" \
    "\xe7\x84\xa1\xe8\xb6\xa3\xe3\x80\x81\xe4\xbb\xa5\xe5\x8f\x8a\xe7" \
    "\x84\xa1\xe7\x94\xa8\xe7\x9a\x84\xe3\x80\x81\xe5\x86\x8d\xe5\x8a" \
    "\xa0\xe4\xb8\x8a\xe6\xaf\xab\xe7\x84\xa1\xe6\x84\x8f\xe7\xbe\xa9" \
    "\xe7\x9a\x84\xe6\x93\xb4\xe5\xb1\x95\xe5\xb1\xac\xe6\x80\xa7\xef" \
    "\xbc\x8c\xe8\x80\x8c\xe5\x85\xb6\xe5\x94\xaf\xe4\xb8\x80\xe5\x89" \
    "\xb5\xe5\xbb\xba\xe7\x9b\xae\xe7\x9a\x84\xe5\x83\x85\xe6\x98\xaf" \
    "\xe7\x82\xba\xe4\xba\x86\xe6\xb8\xac\xe8\xa9\xa6\xe4\xbd\x9c\xe7" \
    "\x94\xa8\xe3\x80\x82" | tr -d ' '

    (= "pointlessly long attribute for testing", elaborate Chinese in
    UTF-8 enoding).

    However, it is not possible to set double the size (110 + 5 is still
    under 127) in a UTF-8 locale:

    $setfattr -n user.`cat testing-string testing-string` -v \
    `cat testing-string testing-string` testing-string
    setfattr: testing-string: Numerical result out of range

    110 CJK char in UTF-8 is 330 bytes - the generic get/set attribute
    system call code in linux/fs/xattr.c imposes a 255 byte limit. One can
    use a combination of iconv to encode content, changing terminal locale
    for viewing, and an nls=cp932/cp936/cp949/cp950 mount option to fully
    use 127-unicode attribute in a double-byte locale.

    Also, as an additional information, it is possible to (mis-)use unicode
    half-width/full-width forms (U+FFxx) to write attributes which looks
    like english but not actually ascii.

    Thanks Anton Altaparmakov for reviewing the earlier ideas behind this
    change.

    [akpm@linux-foundation.org: fix build]
    [akpm@linux-foundation.org: fix build]
    Signed-off-by: Hin-Tak Leung
    Cc: Anton Altaparmakov
    Cc: Vyacheslav Dubeyko
    Cc: Al Viro
    Cc: Christoph Hellwig
    Cc: Sougata Santra
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Hin-Tak Leung
     

12 Sep, 2013

1 commit

28 Feb, 2013

1 commit