Incongruence between cygwin and samba ACL handling

Abramo Bagnara abramo.bagnara@gmail.com
Thu Aug 14 14:40:00 GMT 2008


Corinna Vinschen ha scritto:
> First of all, bug reports like this should go to the main cygwin mailing
> list, not to the developer's list.

Sorry, probably I didn't read the doc with enough attention :-(

> Second, this is long standing behaviour in Cygwin.  I'm surprised that
> nobody has encountered this before.  I guess, since the default is
> "nosmbntsec" in Cygwin 1.5, not many people are really using real
> permissions on Samba.
> 
> I was inclined to say that this is neither a Cygwin, nor a Samba bug,
> since Cygwin has good reasons to set the FILE_READ_ATTRIBUTES and
> FILE_READ_EA flags (Everybody must be able to read this for POSIX
> permission handling) as well Samba has good reasons to set the read
> permission bit if any one of these permission flags is set.

Thinking more about that, I'm tempted to disagree about the latter.

The samba client is asking to inhibit file data reading and samba server
decides to permit that leaving a big security hole.

Suppose that I use attributes to store some file metadata that I want to
leave readable (by example version info or info about the reason of the
the unreadability) while I still want that file content is private.

Now if Joe Luser, as a legitimate reading user, copies or moves this
file to a samba share, the ACL is expanded to contain FILE_READ_DATA.

IMHO when a permission model is mapped in another permission model that
has less or different granularity the resulting permission should be a
subset of the original one.

To use a different policy is inherently dangerous, especially because
this conversion is implicit and user is not informed of consequent data
exposure.

I'm missing something? Which are the good reasons for samba to set the
read permission bit you see?

> Thanks for the report,

Thank you for your attention.

Abramo



More information about the Cygwin-developers mailing list