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] |
On Fri, Sep 17, 2010 at 04:50:40PM +0200, Corinna Vinschen wrote: > On Sep 17 13:59, David Sastre wrote: > > > > Regarding the ITA of these packages, and the proposed patches, I have > > some thoughts to share and discuss before I repackage them. > > > > 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 > > > > 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). > > Tcsh is somewhat different from the other shells because it's using > an entirly different script syntax. > > WHat's wrong with the proposed patch? The only problem I have with it > is the fact that it uses tr and sed to find out what shell it's running > in. There is probably a way to do this without starting more processes. > Like this: > > read x < /proc/self/exename > case "$x" in > */bash) > ... > */dash|*/ash|*/sh) > ... > */ksh) > ... > */zsh) > ... > * > ... Absolutely nothing is wrong with the patch. I'm only thinking about an unified method for supplying skeletal files, regardless the shell. I mean, currently /etc/profile includes logic to deal with all kinds of shells; being mksh an example, a /etc/skel/.mkshrc could be supplied, to source a system-wide /etc/mkshrc provided by the mksh package, this is a simplified example taken from Debian: case $KSH_VERSION in *MIRBSD\ KSH*) ;; *) return 0 ;; esac [[ -s /etc/mkshrc ]] && . /etc/mkshrc This would be my solution to nº2 and nº3 above, i.e. PS1 is correctly set and inherited, because every shell that needs it, provides a system-wide *rc file to set PS1 and HOSTNAME, distributed with that shell's package. I think this is positive because it frees /etc/profile from a work that can be done by the shells on-demand. Base-files would only provide /etc/defaults/etc/skel/.${SHELL}rc files to source /etc/${SHELL}rc, installed by the packages, unneeded otherwise. BTW, mksh is the only *ksh shell in the distro, being pdksh orphaned and unmaintained upstream. Also, I am curious to know if there is a reason why /etc/defaults/etc/profile.d/lang.csh is not included in tcsh. > > 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. > > I agree with Chris. Let's keep them separate. I can imagine that the > process to create default /etc/passwd and /etc/group files might change > in the future (more intelligent, no such files at all, you name it), and > there's no reason to change base-files in that case. OK. No problem. > > 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. > > It's good enough for a start. If we come up with a better solution, > we can still change it, right? All right. -- 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] |