Solaris only uses one colon in the listing of the ACL mask, Linux uses two,
so substitute egrep for grep and make the second colon optional.
The -q option for Solaris 7's /usr/xpg4/bin/egrep does not appear to be
implemented, so redirect output to /dev/null.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some implementations of setfacl do not recalculate the effective rights
mask when the ACL is modified. So, set the effective rights mask
explicitly to ensure that the ACL's that are set on the directories will
have effect.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This test was using the group read permission bit as an indicator of the
default ACL mask. This behavior is valid on Linux but not on other
platforms like Solaris. So, rather than looking at mode bits, just test
readability for the user. This, along with the checks for the existence
of the ACL's that were set on the parent directories, should be enough.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
According to the Linux setfacl man page, in order for an ACL to be valid,
the following rules must be satisfied:
* Whenever an ACL contains any Default ACL entries, the three Default
ACL base entries (default owner, default group, and default others)
must also exist.
* Whenever a Default ACL contains named user entries or named group
objects, it must also contain a default effective rights mask.
Some implementations of setfacl (Linux) do this automatically when
necessary, some (Solaris) do not. Solaris's setfacl croaks when trying to
create a default user ACL if the above rules are not satisfied. So, create
them before modifying the default user ACL's.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some platforms (Solaris) have a setfacl whose -d switch works differently
than the one on Linux. On Linux, it causes all operations to be applied
to the Default ACL. There is a notation for operating on the Default ACL:
[d[efault]:] [u[ser]:]uid [:perms]
so use it instead of the -d switch.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We used to unnecessarily give the read permission to group and others,
regardless of the umask, which isn't serious because the objects are
still protected by their containing directory, but isn't necessary
either.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We used to create 0600 files, and then use chmod to set the group and
other permission bits to the umask. This usually has the same effect
as a normal file creation with a umask.
But in the presence of ACLs, the group permission plays the role of
the ACL mask: the "g" bits of newly created files are chosen according
to default ACL mask of the directory, not according to the umask, and
doing a chmod() on these "g" bits affect the ACL's mask instead of
actual group permission.
In other words, creating files with 0600 and then doing a chmod to the
umask creates files which are unreadable by users allowed in the
default ACL. To create the files without breaking ACLs, we let the
umask do it's job at the file's creation time, and get rid of the
later chmod.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Right now, Git creates unreadable pack files on non-shared
repositories when the user has a umask of 077, even when the default
ACLs for the directory would give read/write access to a specific
user.
Loose object files are created world-readable, which doesn't break ACLs,
but isn't necessarily desirable.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
