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]

Re: [ITA] - base-files base-passwd


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]