X-Recipient: archive-cygwin AT delorie DOT com DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:message-id:in-reply-to:subject :mime-version:content-type:content-transfer-encoding; q=dns; s= default; b=rKfw151f9LqLj0IzRg5/d7MpKzFrfYlVGL3a0n2+80MSClHz9qh3z JqU53XYr8VqT/ayPrsjfI8zi+OGGU7HxdD9dkdK7SEJ7cX00CJPrDRTpSobdm5pq K7MBAVYtGdWvrYMwf7iwiFfn0lYS2wrATUAlWIb9E7baXpVm19pGRc= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:message-id:in-reply-to:subject :mime-version:content-type:content-transfer-encoding; s=default; bh=7tKNpu1DV3eDKhLip7z8cl8uRFg=; b=AqADZP99wVZ05Of1UB8+Lonc8C1f Pde5GCEjc/LjS0jaNk2cf9ei0wZ3OXE6IGnCcxmCvpH5JH7xwHLdWDbdmZZLrTPc ySz/iI8t2stWXBlQoH80Xftk61T7swyeMDWRPj4VVhNQi+ufD9tGAgHsaJZ+/GNc UD9cdCZHKngOxOw= Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=4.4 required=5.0 tests=AWL,BAYES_60,FREEMAIL_FROM,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 spammy=H*M:root, aucun, deny, accs X-HELO: smtp1-g21.free.fr Date: Sat, 5 Mar 2016 18:49:45 +0100 (CET) From: akikij AT free DOT fr To: cygwin AT cygwin DOT com Message-ID: <1160735037.124947226.1457200185315.JavaMail.root@zimbra93-e16.priv.proxad.net> In-Reply-To: <550385091.121913198.1457106187258.JavaMail.root@zimbra93-e16.priv.proxad.net> Subject: Re: Issues with ACL settings after updating to the latest cygwin.dll - correction MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Authenticated-User: akikij AT free DOT fr Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id u25Ho2jP002527 Hi, Corinna To be clear about my problems about ACL. A very simple example to observe. I go to the root disk (C:\ or /cygdrive/c upon the system) I can't create a file here (normally protected). So I use administrator rights to do that with cmd and bash. In cmd : C:\>echo > xx C:\>cacls xx C:\xx BUILTIN\Administrateurs:(ID)F AUTORITE NT\Système:(ID)F BUILTIN\Utilisateurs:(ID)R AUTORITE NT\Utilisateurs authentifiés:(ID)C Sorry I am french, but I say Ok why not. In bash : user AT HOST /cygdrive/c -- my prompt bash not repeated after $ echo > x $ cacls x C:\x NULL SID:(DENY)(accès spécial :) READ_CONTROL FILE_WRITE_EA FILE_EXECUTE FILE_DELETE_CHILD ASUS38\andre:(accès spécial :) STANDARD_RIGHTS_ALL DELETE READ_CONTROL WRITE_DAC WRITE_OWNER SYNCHRONIZE STANDARD_RIGHTS_REQUIRED FILE_GENERIC_READ FILE_GENERIC_WRITE FILE_READ_DATA FILE_WRITE_DATA FILE_APPEND_DATA FILE_READ_EA FILE_WRITE_EA FILE_READ_ATTRIBUTES FILE_WRITE_ATTRIBUTES BUILTIN\Administrateurs:(DENY)(accès spécial :) FILE_EXECUTE AUTORITE NT\Utilisateurs authentifiés:(DENY)(accès spécial  FILE_EXECUTE AUTORITE NT\Système:(DENY)(accès spécial :) FILE_EXECUTE BUILTIN\Utilisateurs:(DENY)(accès spécial :) FILE_EXECUTE ASUS38\Aucun:(accès spécial :) READ_CONTROL SYNCHRONIZE FILE_GENERIC_READ FILE_READ_DATA FILE_READ_EA FILE_READ_ATTRIBUTES BUILTIN\Administrateurs:(accès spécial :) READ_CONTROL SYNCHRONIZE FILE_GENERIC_READ FILE_GENERIC_WRITE FILE_GENERIC_EXECUTE FILE_READ_DATA FILE_WRITE_DATA FILE_APPEND_DATA FILE_READ_EA FILE_WRITE_EA FILE_EXECUTE FILE_READ_ATTRIBUTES FILE_WRITE_ATTRIBUTES AUTORITE NT\Utilisateurs authentifiés:(accès spécial :) READ_CONTROL SYNCHRONIZE FILE_GENERIC_READ FILE_GENERIC_WRITE FILE_GENERIC_EXECUTE FILE_READ_DATA FILE_WRITE_DATA FILE_APPEND_DATA FILE_READ_EA FILE_WRITE_EA FILE_EXECUTE FILE_READ_ATTRIBUTES FILE_WRITE_ATTRIBUTES AUTORITE NT\Système:(accès spécial :) READ_CONTROL SYNCHRONIZE FILE_GENERIC_READ FILE_GENERIC_WRITE FILE_GENERIC_EXECUTE FILE_READ_DATA FILE_WRITE_DATA FILE_APPEND_DATA FILE_READ_EA FILE_WRITE_EA FILE_EXECUTE FILE_READ_ATTRIBUTES FILE_WRITE_ATTRIBUTES BUILTIN\Utilisateurs:R Tout le monde:(accès spécial :) READ_CONTROL SYNCHRONIZE FILE_GENERIC_READ FILE_READ_DATA FILE_READ_EA FILE_READ_ATTRIBUTES ------------- Sorry, it's a very long data and I can't really say if it's ok or not. Why such as complexity ? I understand the DENY FILE_EXECUTE (It's the unix philosophy for file creation) I don't understand NULL SID DENY - and how it's translated in getfacl. Now if I compare cacls xx created by cmd they are same in bash and cmd. Now if I compare getfacl (more readable) for x and of xx, I have : $ getfacl.exe x # file: x # owner: user # group: Aucun user::rw- group::r-- group:root:rwx #effective:rw- group:Utilisateurs authentifiés:rwx #effective:rw- group:Système:rwx #effective:rw- group:Utilisateurs:r-x #effective:r-- mask:rw- other:r-- $ getfacl.exe xx # file: xx # owner: Administrateurs # group: Aucun user::rwx group::--- group:Utilisateurs authentifiés:rwx group:Système:rwx group:Utilisateurs:r-x mask:rwx other:--- All that to say, ACLs affected to file are may be surprising but work A LITTLE BIT, yes more ... But in some cases NOT. In my cygwin application, sometimes I fall in a situation where I am obliged to reorder the ACEs to continue correctly. I say obliged and it's the first problem. Who create this situation ? Always I have seen a NULL SID ACE in such a case. That's the reason I don't like it. I don't know when the problem occur. I never encounter NULL SID outside of cygwin environment. Why sometimes in /bin and /lib ... this case occurs. I try to show a reproductive case of my problem. Regards -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple