Re: [PATCH setup] Add new option --chown-admin
Jon Turney wrote: On 04/10/2022 13:05, Christian Franke wrote: Jon Turney wrote: Corinna had some concerns about making the owner a group, rather than a user, which I believe historically caused some difficulties in Cygwin, so I think I'll need to understand that better before making a decision about this change. I see. Do you have any info about these difficulties? Are these still relevant? If yes, let's forget this patch. After a bit of research, I think the issue was that if you make user owner and group owner map onto the same Windows SID, certain unix access permissions cannot be reversibly mapped onto a Windows ACL. (e.g you can't set the mode to 0600, because when you read that back, it's mode is 0660. Some programs e.g ssh check for and require 0600 permission on some files) No and yes. No, a quick test shows that stat() returns what chmod() sets even in this case: # for p in 600 640 660 644 664; do f=perm-$p && touch $f && chown Administrators.Administrators $f && chmod $p $f && ls -l $f done -rw--- 1 Administrators Administrators 0 Nov 30 18:39 perm-600 -rw-r- 1 Administrators Administrators 0 Nov 30 18:39 perm-640 -rw-rw 1 Administrators Administrators 0 Nov 30 18:39 perm-660 -rw-r--r-- 1 Administrators Administrators 0 Nov 30 18:39 perm-644 -rw-rw-r-- 1 Administrators Administrators 0 Nov 30 18:39 perm-664 The above likely works due to some heuristic based on ACE order. Yes, the effective permissions of 0600 are always the same as 0660 because the first ACE is already for the group: # icacls perm-\* perm-600 BUILTIN\Administrators:(R,W,D,WDAC,WO) BUILTIN\Administrators:(Rc,S,RA) Everyone:(Rc,S,RA) perm-640 BUILTIN\Administrators:(R,W,D,WDAC,WO) BUILTIN\Administrators:(R) Everyone:(Rc,S,RA) perm-644 BUILTIN\Administrators:(R,W,D,WDAC,WO) BUILTIN\Administrators:(R) Everyone:(R) perm-660 BUILTIN\Administrators:(R,W,D,WDAC,WO) BUILTIN\Administrators:(R,W) Everyone:(Rc,S,RA) perm-664 BUILTIN\Administrators:(R,W,D,WDAC,WO) BUILTIN\Administrators:(R,W) Everyone:(R) (Tests done on German Windows and localized names renamed afterwards). This perhaps isn't terribly relevant to files created by setup It may depend on how access checks are done by ssh etc.. (mode bits or effective permissions).
Re: [Bug] setup regression #2
Jon Turney wrote:
On 20/11/2022 19:05, Achim Gratz wrote:
Jon Turney writes:
I believe that the intent of the code in setup is that there should
only be two modes:
USER: install "for me", with the users primary group
As I understand it, the intention here was that the user can have a
"single user installation" in a place that they have access to (say,
their home directory) while they have no permission in one of the usual
places. In a setup where that place is a certain type of share the user
will not be able to change the group the files are owned by anyway
(standard NetApp CIFS shares are set up this way) and it may not be the
users primary group.
SYSTEM: install "for everyone", with the administrators primary group
(only permitted if you are an administrator)
I don't see why the fact the installation is meant to be used by
multiple users means that the install must be owned by group
Administrators. I'm not sure this is a good idea on Windows anyway, at
least when you don't put extra (inheritable) DACL on the install
folder.
Christian,
Maybe you can offer your opinion here, since you seem to have the
opposite, or at least a different, point of view.
Anything installed with "All Users" option should IMO be protected
against modifications by any regular non-elevated user.
This is not the case if the RID=513 group ("HOST\None",
"DOMAIN\Domain-Users") is used. Many upstream projects install
directories and files with permissions like 0664, 0775, 0660 or 0770.
This is safe when the group is "root". On current Cygwin, all users have
R/W access regardless of the "other" permission bits.
Try for example: find /usr/share ! -type l -perm -020 -ls (~4000 hits on
my installation)
Using the administrators group as discussed here would solve this but
apparently introduces interesting new permission problems with some
packages. Could these possibly be solved by the maintainers of the
affected packages?
An alternative may be: Keep the group as is, but prevent using above
permissions as far as possible. For new packages, this could possibly be
done with an enhancement of cygport. But I'm sure that there will also
be subtle cases where these modified permissions break things. Cygport
could allow to opt-out then.
Ideally the protection should also be effective for the non-elevated
user who runs setup elevated. This is automatically the case for typical
installers because Windows changes TokenOwner to administrators group if
run elevated. That's why I provided
https://sourceware.org/pipermail/cygwin-apps/2022-August/042221.html
Re: cygwin-pkg-maint cleanup
On 11/29/2022 4:36 PM, Jon Turney wrote: xemacs ORPHANED (Dr. Volker Zell) Is it dead yet? Not completely: https://cygwin.com/pipermail/cygwin/2021-November/249814.html https://foss.heptapod.net/xemacs/xemacs Ken
Re: cygwin-pkg-maint cleanup
On Tue, 2022-11-29 at 21:36 +, Jon Turney wrote: > I've done another clean-up of cygwin-pkg-maint, removing those source > packages names which no longer exist after x86 was archived (i.e only > existed as x86 packages) > > > cygwin64-* ORPHANED (Yaakov Selkowitz) 32-bit only by design Is there a point in keeping the cygwin32-* packages around any longer? -- Yaakov
