This is the mail archive of the cygwin-apps mailing list for the Cygwin project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Hello, Regarding the ITA of these packages, and the proposed patches, I have some thoughts to share and discuss before I repackage them. 1 http://sourceware.org/ml/cygwin/2010-04/msg00521.html case sensitivity of system32 dir (win7 and vista) 2 http://cygwin.com/ml/cygwin/2010-02/msg00503.html PS1 not inherited by interactive shells with a non interactive ancestry 3 http://sourceware.org/ml/cygwin/2010-05/msg00000.html PS1 setting for *ksh shells 4 Merging base-files and base passwd together. 5 http://cygwin.com/ml/cygwin-developers/2010-09/msg00007.html /home security problem 1 This is a simple fix, so it'd be applied. 2 This could be solved by redefinig the skeletal files for every shell (more below). 3 This one might deserve some discussion: Because of, as of now, the default shell in cygwin is bash, as I see it, there are two possible approaches: a) base-files provides the skel defaults and profile.d/ for the bash shell and delegates in the other shells' packages the way they want to set PS1, and/or have /etc/${SYSTEM_WIDE_RC} and/or /etc/skel/.{USER_RC} and/or /etc/profile.d/${CUSTOM_FILES} and/or update the alternatives system. (bash->sh, tcsh->csh, mksh->ksh, etc...). The same would apply for every shell (bash, mksh, tcsh, posh, dash). This is currently the approach in the case of tcsh (except for /etc/defaults/etc/profile.d/lang.csh) b) base-files provides skel defaults and profile.d customizations for every shell (some are common: i.e. /etc/skel/.profile). What do you people think? 4 Can we consider this? what are the circular dependencies in that scenario? AFAICT, including base-passwd in base-files, and afterwards dropping base-passwd dependencies anywhere else should be harmless. 5 As stated in the referenced thread, there is no way to prevent attackers to create a user's home dir before she/he logins the first time other than disallowing anyone but the Administrator to do that. If the proposed workaround (issuing a warning if $HOME already exists and is owned by someone else) is considered enough, I'll include it. I haven't thought of anything better than that. TIA for the feedback. -- Huella de clave primaria: 0FDA C36F F110 54F4 D42B D0EB 617D 396C 448B 31EB
Attachment:
signature.asc
Description: Digital signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |