bugacl - Bugs: bug #51818, setfacl w/ default ACL doesn't...

 
 

bug #51818: setfacl w/ default ACL doesn't always set setgid bit in newly created sub-directories

Submitter:  Julien Chiaramello <jchiaramello>
Submitted:  Tue 22 Aug 2017 06:55:33 AM UTC
   
 
Category:  None Severity:  3 - Normal
Item Group:  None Status:  Invalid
Privacy:  Public Assigned to:  None
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Tue 22 Aug 2017 09:48:01 AM UTC, comment #1: 

This is a kernel rather than a setfacl bug.  The bug was introduced in v4.9-rc1 by commit 07393101, and fixed around v4.13-rc4 by various commits depending on the filesystem used.  The ext4 fix is a3bb2d55.  Here are some details:

commit 073931017b49d9458aa351605b43a7e34598caef
Author: Jan Kara <jack@suse.cz>
Date:   Mon Sep 19 17:39:09 2016 +0200

    posix_acl: Clear SGID bit when setting file permissions
   
    When file permissions are modified via chmod(2) and the user is not in
    the owning group or capable of CAP_FSETID, the setgid bit is cleared in
    inode_change_ok().  Setting a POSIX ACL via setxattr(2) sets the file
    permissions as well as the new ACL, but doesn't clear the setgid bit in
    a similar way; this allows to bypass the check in chmod(2).  Fix that.
   
    References: CVE-2016-7097
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Jeff Layton <jlayton@redhat.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>

commit a3bb2d5587521eea6dab2d05326abb0afb460abd
Author: Jan Kara <jack@suse.cz>
Date:   Sun Jul 30 23:33:01 2017 -0400

    ext4: Don't clear SGID when inheriting ACLs
   
    When new directory 'DIR1' is created in a directory 'DIR0' with SGID bit
    set, DIR1 is expected to have SGID bit set (and owning group equal to
    the owning group of 'DIR0'). However when 'DIR0' also has some default
    ACLs that 'DIR1' inherits, setting these ACLs will result in SGID bit on
    'DIR1' to get cleared if user is not member of the owning group.
   
    Fix the problem by moving posix_acl_update_mode() out of
    __ext4_set_acl() into ext4_set_acl(). That way the function will not be
    called when inheriting ACLs which is what we want as it prevents SGID
    bit clearing and the mode has been properly set by posix_acl_create()
    anyway.
   
    Fixes: 073931017b49d9458aa351605b43a7e34598caef
    CC: -email is unavailable-
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Reviewed-by: Andreas Gruenbacher <agruenba@redhat.com>

Andreas Gruenbacher <agruen>
Group administrator
Tue 22 Aug 2017 06:55:33 AM UTC, original submission:  

When a directory has both a default ACL and the setgid bit set, the setgid bit will only be propagated to subdirectories if their creator belongs to the group that owns the parent directory - this is inconsistent with behavior without default ACL which always propagates setgid regardless of permissions or ownership.

Tests were made with the acl version 2.2.52-3+b1 on Debian Stretch (9.1)

Original Debian bug report (Includes more details and steps to reproduce) : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=694756

Julien Chiaramello <jchiaramello>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by agruen (Posted a comment)
  • -email is unavailable- added by jchiaramello (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2017-08-22 agruen StatusNone Invalid
        Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-4b48.
    Corresponding source code