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]

[ITA] - base-files base-passwd


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]