Bug 599172

Summary:	=sys-apps/apply-default-acl-0.0.6 stabilization
Product:	Gentoo Linux	Reporter:	Michael Orlitzky <mjo>
Component:	Current packages	Assignee:	Michael Orlitzky <mjo>
Status:	RESOLVED FIXED
Severity:	normal	Keywords:	STABLEREQ
Priority:	Normal
Version:	unspecified
Hardware:	All
OS:	Linux
Whiteboard:
Package list:		Runtime testing required:	---

Description Michael Orlitzky gentoo-dev

2016-11-08 03:22:30 UTC

Arches, please stabilize this. If you have ACL support on your filesystems, apply-default-acl can be tested by creating a new directory, giving it a default ACL, copying a file into it, and then running apply-default-acl on the file. The ACL on the file should be overwritten with the default one from the directory.

For example,

  $ mkdir acl
  $ cd acl
  $ setfacl -d -m user:daemon:rwx .
  $ cp /etc/profile ./

The "daemon" user should have read/write permission on the copy of "profile", but it won't:

  $ getfacl --omit-header profile 
  user::rw-
  user:daemon:rwx		#effective:r--
  group::r-x			#effective:r--
  mask::r--
  other::r--

The point of apply-default-acl is to fix that:

  $ apply-default-acl profile
  $ getfacl --omit-header profile
  user::rw-
  user:daemon:rwx		#effective:rw-
  group::r--
  mask::rw-
  other::r--

I've already tested this extensively on amd64, and somewhat on x86. The only changes in this version compared to the current stable are,

  1. An error is output if you give it a bad path.
  2. Symlinks are handled as documented (bugfix).

Comment 1 Michael Orlitzky gentoo-dev

2016-12-12 14:32:21 UTC

I've stabilized this myself. I'm the upstream author as well, so I use it regularly and know how to e.g. trick the test suite into running against the system copy. Everything is OK =)