Mailing-List: contact cygwin-developers-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-developers-owner AT cygwin DOT com Delivered-To: mailing list cygwin-developers AT cygwin DOT com Date: Tue, 10 Dec 2002 11:24:03 +0100 From: Corinna Vinschen To: cygwin-developers AT cygwin DOT com Subject: Re: ntsec, inheritance and sec_acl Message-ID: <20021210112403.B7796@cygbert.vinschen.de> Reply-To: cygwin-developers AT cygwin DOT com Mail-Followup-To: cygwin-developers AT cygwin DOT com References: <3 DOT 0 DOT 5 DOT 32 DOT 20021205222631 DOT 007d3920 AT mail DOT attbi DOT com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3.0.5.32.20021205222631.007d3920@mail.attbi.com> User-Agent: Mutt/1.3.22.1i Hi Pierre, sorry for the delay. On Thu, Dec 05, 2002 at 10:26:31PM -0500, Pierre A. Humblet wrote: > There is a thread on the cygwin list > http://cygwin.com/ml/cygwin/2002-11/msg01127.html > where ntsec is blamed for permission troubles with > non cygwin applications. Yes, I read it. > [snip] > - What behavior are we trying to achieve? The inheritance is only to support Windows natives. > - If we do not set any inheritances on directories and a file is > created, by default the user (or Administrators) and System > have full access, period. That's clearly worse than today. I agree. > - Should we set inheritance rights for "well_known_creator_owner_sid" > (and not for the directory owner sid)? > For the group, define similarly a "well_known_creator_group_sid" > (S-1-3-1). > That is, we could insert these special sids in INHERIT_ONLY ACEs on > directories, mirroring the owner/group/everyone, both deny and > allow. I have verified that the inherited ACEs have the correct > order, even if it isn't canonical. I made the same tests on XP today and I'm impressed. I recall that I once tested using creator_owner and creator_group (I don't know on which system) and for some reason I treated it unusable. Perhaps just due to the GUI ACL interface or I didn't use the correct inheritance rules. It looks very usable now, though. I tried the following: owner ACE: This folder only creator_owner ACE: Only subfolders and files group ACE: This folder only creator_group ACE: Only subfolders and files everyone ACE: This folder, subfolders and files This results in (even from a POSIX view) correct ACLs for newly created files and the same plus the additional entries for creator_owner and creator_group for new subdirectories. Interesting: If the everyone entry doesn't allow creating files, an unrelated user can't create files, regardless of the rights given to the creator_owner and creator_group ACEs. And: Even though all users are members of the same primary group 'None' on workstations, they can't suddenly create files because the creator_group entry has e. g. full permissions. So, from what I can tell, this seems like the way to go. > - Or should we simply give INHERIT_ONLY full access to Everyone? > (probably least likely to generate complaints, but least secure). > One advantage of this last approach is that such an ACE could easily > be detected and suppressed in the getacl code, and "normal" cygwin > directories would stop having a "+" in ls -l. I don't see an advantage. Wouldn't it make sense just to remove the creator_owner and creator_group entries from the acl_t completely, perhaps? Hmm, that's only a problem if we actually are concerned by the additional '+' in the ls output. Are we? OTOH, this invalidates the chance to create the correct default:user:: entries in getfacl output... looks like we cannot have both. Another problem is that this only makes sense if there are write permissions present for everyone or the group entry. Or for an unrelated group or user entry. That's tricky. If *anybody* has write access to the directory, the everyone inheritance would then give *everybody* write access. Oh oh... > A related matter is that the getfacl output for "." above is incorrect. > For example, the line "default:user::rwx" > should be "default:user:PHumblet:rwx" > i.e. apply to a specific user although PHumblet is the owner. > This is easily seen from the output of "getfacl testuser_nontsec" > > An unnamed user line "default:user::abc" > should only be generated when well_known_creator_owner_sid is > present. Similarly for group. In the light of the above discussion, yes, you're right. > Following an unrelated problem using setfacl, I have looked more into > the acl functions and noticed difference with Sun on two points: > the number of colons and on the input formats > See below. Comments on right side. "midi" is a Sun. > [snip] > I can take a stab at some of this after we finish the internal > passwd business and converge on what to do about inheritances. Ok, I didn't notice this difference. We can change that at a later point. It doesn't really matter unless we actually use the creator_owner and creator_group entries. I'm trying to review (finally) your second patch to the internal passwd patch today or tomorrow. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developer mailto:cygwin AT cygwin DOT com Red Hat, Inc.