Re: Bugreport on Ubuntu LTS: not ok - 2 Objects creation does not break ACLs with restrictive umask

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Jun 05, 2012 at 10:10:39AM -0400, Jeff King wrote:

> On Tue, Jun 05, 2012 at 10:04:49AM -0400, Jeff King wrote:
> 
> >   # and create some files with different permissions
> >   perl -MFcntl -e '
> >     sysopen(X, "a", O_WRONLY|O_CREAT, 0666);
> >     sysopen(X, "b", O_WRONLY|O_CREAT, 0600);
> >   '
> Hmm, no I'm wrong. That is OK, as the mask should be restricted by the
> group permission (and it is on ext4, too). But when I traced through
> git, the tmp_obj_* files are created with the right permissions on ext4,
> but not on ecryptfs. Let me trace through it again...<sigh>

OK, here's the _real_ issue. Git creates with mode 0444, which should
still allow read in the mask. But it's the restrictive umask at the top
of the test script that causes the problem. Try this:

  setfacl -m m:rwx .
  perl -MFcntl -e 'sysopen(X, "a", O_WRONLY|O_CREAT, 0444)'
  umask 077
  perl -MFcntl -e 'sysopen(X, "b", O_WRONLY|O_CREAT, 0444)'
  getfacl a b

On ext4, both files will have the read bit set in the mask. On ecryptfs,
"b" will have an empty mask. I think the wrong thing is that we should
not be respecting umask at all when default ACLs are in play, and
ecryptfs is getting that wrong. But I'm having trouble digging up an
authoritative source.

-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]