Re: /etc/shells #include syntax support patch
Mike Meyer stated:
: [EMAIL PROTECTED] types:
: > At 29 Jan 2001 11:49:36 +0100,
: > Dag-Erling Smorgrav <[EMAIL PROTECTED]> wrote:
: > > No. Mergemaster doesn't care about the contents of the file, only
: > > about its $FreeBSD$ tag. As long as this stays the same, it'll leave
: > > the file alone. If you remove the $FreeBSD$ tag in the installed file
: > > or someone commits to src/etc/shells, mergemaster will prompt you.
: > I want mergemaster(8) to have a list not to compare. It is not
: > necessary for mergemaster(8) to compare host specific files, for
: > example, /etc/hosts, /etc/printcap and /etc/shells, to their
: > originals in /usr/src. I want that system managers for local
: > hosts can decide which files follow the source and which files
: > do not.
:
: There was some discussion of about this on -questions (I think it was)
: a while back, and the author commented on some things he was working
: on. You might look through those, then nudge him about it.
You have been able to do it with mergemaster for quite some time
now. How I do this is to add
MM_PRE_COMPARE_SCRIPT='/path/to/my/mmprecompare.sh'
to my (and hence root .. I use sudo) .mergemasterrc file. And
mmprecompare.sh consists of:
<- snip >
#! /bin/sh
# Create a log file ??
DATE=`date +%Y%m%d`
LOGFILE="/tmp/mergemaster-${DATE}"
# Ignore these files
IGNORE_LIST="/.cshrc \
/etc/mail/aliases \
/etc/csh.cshrc \
/etc/csh.login \
/etc/dhclient.conf \
/etc/group \
/etc/hosts \
/etc/hosts.allow \
/etc/hosts.equiv \
/etc/hosts.lpd \
/etc/mail/sendmail.cf \
/etc/master.passwd \
/etc/namedb/PROTO.localhost.rev \
/etc/namedb/make-localhost \
/etc/namedb/named.conf \
/etc/namedb/named.root \
/etc/newsyslog.conf \
/etc/printcap \
/etc/ssh/ssh_config \
/etc/ssh/sshd_config \
/etc/syslog.conf \
/etc/ttys \
/root/.cshrc \
/root/.login"
#
# remove w/o complaint the files in question
#
for IGNORE in ${IGNORE_LIST}
do
#
IDENT1=`ident "${DESTDIR}${IGNORE}" 2>&1`
IDENT2=`ident "${TEMPROOT}${IGNORE}" 2>&1`
case "${IDENT2}" in
*'no id keywords'*)
;;
."${IDENT1}")
# No worries ???
# echo " *** ${DESTDIR}${IGNORE} is the same ***" | tee "${LOGFILE}"
;;
*)
# Ruh-Roh!
echo " *** ${DESTDIR}${IGNORE} has changed! ***" | tee "${LOGFILE}"
;;
esac
#
rm "${TEMPROOT}${IGNORE}"
done
#
<- snip >
--
101-01010101010
Sean O'Connell [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: /etc/shells #include syntax support patch
[EMAIL PROTECTED] types: > At 29 Jan 2001 11:49:36 +0100, > Dag-Erling Smorgrav <[EMAIL PROTECTED]> wrote: > > No. Mergemaster doesn't care about the contents of the file, only > > about its $FreeBSD$ tag. As long as this stays the same, it'll leave > > the file alone. If you remove the $FreeBSD$ tag in the installed file > > or someone commits to src/etc/shells, mergemaster will prompt you. > I want mergemaster(8) to have a list not to compare. It is not > necessary for mergemaster(8) to compare host specific files, for > example, /etc/hosts, /etc/printcap and /etc/shells, to their > originals in /usr/src. I want that system managers for local > hosts can decide which files follow the source and which files > do not. There was some discussion of about this on -questions (I think it was) a while back, and the author commented on some things he was working on. You might look through those, then nudge him about it. http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /etc/shells #include syntax support patch
At 29 Jan 2001 11:49:36 +0100, Dag-Erling Smorgrav <[EMAIL PROTECTED]> wrote: > No. Mergemaster doesn't care about the contents of the file, only > about its $FreeBSD$ tag. As long as this stays the same, it'll leave > the file alone. If you remove the $FreeBSD$ tag in the installed file > or someone commits to src/etc/shells, mergemaster will prompt you. I want mergemaster(8) to have a list not to compare. It is not necessary for mergemaster(8) to compare host specific files, for example, /etc/hosts, /etc/printcap and /etc/shells, to their originals in /usr/src. I want that system managers for local hosts can decide which files follow the source and which files do not. -- SASAKI Shigeo Akita Univeristy, Japan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /etc/shells #include syntax support patch
On Mon, 29 Jan 2001 11:31:32 -0500 (EST) Garrett Wollman <[EMAIL PROTECTED]> wrote: GW> I would rather have a single file, located in a directory intended for GW> configuration files. Perhaps we could call it ``/etc/shells'' which GW> seems to be popular. As you wish. I have no axe to grind, it was fun and instructive to do, seemed to fit the expressed wishes of some people and I could think of some uses for it. If opinions change you know where to find some code :) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /etc/shells #include syntax support patch
On Mon, Jan 29, 2001 at 11:31:32AM -0500, Garrett Wollman wrote: > < said: > > I would rather that a separate configuration file be read, for example, > > with a list of shells(5) format files to consult. > > I would rather have a single file, located in a directory intended for > configuration files. Perhaps we could call it ``/etc/shells'' which > seems to be popular. > > There is no inherent virtue in having (some subset of) configuration > files on every partition. Actually I agree: I don't think anything needs to change. But, if a `feature' such as this _does_ go in, I don't want it to mean that there is a `new' format for `/etc/shells'. -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /etc/shells #include syntax support patch
< said: > I would rather that a separate configuration file be read, for example, > with a list of shells(5) format files to consult. I would rather have a single file, located in a directory intended for configuration files. Perhaps we could call it ``/etc/shells'' which seems to be popular. There is no inherent virtue in having (some subset of) configuration files on every partition. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /etc/shells #include syntax support patch
Vadim Belman <[EMAIL PROTECTED]> writes: > On Sun, Jan 28, 2001 at 11:53:50PM -0500, Louis A. Mamakos wrote: > > It doesn't seem unreasonable to have a single file with a list of allowable > > shells. > It does if you think of mergemaster, for example. With any upgrade > it consider /etc/shells as changed and prompts for replacing/merging/etc. No. Mergemaster doesn't care about the contents of the file, only about its $FreeBSD$ tag. As long as this stays the same, it'll leave the file alone. If you remove the $FreeBSD$ tag in the installed file or someone commits to src/etc/shells, mergemaster will prompt you. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /etc/shells #include syntax support patch
On Sun, Jan 28, 2001 at 11:53:50PM -0500, Louis A. Mamakos wrote: > Does this capability really need to exist (e.g., supporting many files)? It > would seem like the additional complexity would be not what you want for what's > essentially a security policy mechansim. Who gets to own these included files? > What should their permissions be allowed to be? > > It doesn't seem unreasonable to have a single file with a list of allowable > shells. It does if you think of mergemaster, for example. With any upgrade it consider /etc/shells as changed and prompts for replacing/merging/etc. -- /Voland Vadim Belman E-mail: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /etc/shells #include syntax support patch
/etc/shells is such a simple file, I don't see much of point in polluting it. There is not much of difference having a port install: target edit /etc/shells verses editing /usr/local/etc/shells. It should just edit /etc/shells. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /etc/shells #include syntax support patch
On Sun, 28 Jan 2001 23:53:50 -0500 "Louis A. Mamakos" <[EMAIL PROTECTED]> wrote: LM> It doesn't seem unreasonable to have a single file with a list of allowable LM> shells. One thing - it is kind of cute having the allowable shells match the mounted shells. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /etc/shells #include syntax support patch
On Sun, 28 Jan 2001 22:19:29 -0800 (PST) John Baldwin <[EMAIL PROTECTED]> wrote: JB> People whine about the problem though, so having no solution doesn't JB> help either. Since #include is syntatically a comment, it shouldn't JB> mess up other programs, though the idea is that they will all use the JB> API in libc and not be reading the file themselves. However, I do JB> think that doing it through nsswitch might be the best solution. Everything in the tree uses the API apart from adduser.perl. Do many ports use /etc/shells ? On the security issue, I rather like the idea that a none root port administrator is possible, this doesn't really need multiple shells files though so nsswitch works for me. I can't set it up though (no -current box). To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /etc/shells #include syntax support patch
On 29-Jan-01 Louis A. Mamakos wrote: >> On Sun, Jan 28, 2001 at 10:13:49AM +0100, Steve O'Hara-Smith wrote: >> >Hi, >> > >> >Asbestos suit on, round two. >> > >> >The patch below changes getusershell to support a #include syntax >> > in /etc/shells. >> >> I guess this is what I object to. I don't particularly like having a >> new directive in a configuration file which lots of applications read >> directly. >> >> I would rather that a separate configuration file be read, for example, >> with a list of shells(5) format files to consult. >> >> In current, this could be an optional thing, activated in nsswitch.conf, >> e.g. make a ports source for shells, and activate it with: >> shells: files ports >> >> or whatever you would like to call the source. > > Does this capability really need to exist (e.g., supporting many files)? It > would seem like the additional complexity would be not what you want for > what's > essentially a security policy mechansim. Who gets to own these included > files? > What should their permissions be allowed to be? > > It doesn't seem unreasonable to have a single file with a list of allowable > shells. > > Is this #include capability going to be added for other files that ports > modify such as /etc/master.passwd and /etc/group? > > I dunno; maybe it's just me, but this really seems like a solution way out > of proportion to the "problem" People whine about the problem though, so having no solution doesn't help either. Since #include is syntatically a comment, it shouldn't mess up other programs, though the idea is that they will all use the API in libc and not be reading the file themselves. However, I do think that doing it through nsswitch might be the best solution. > louie -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /etc/shells #include syntax support patch
> On Sun, Jan 28, 2001 at 10:13:49AM +0100, Steve O'Hara-Smith wrote: > > Hi, > > > > Asbestos suit on, round two. > > > > The patch below changes getusershell to support a #include syntax > > in /etc/shells. > > I guess this is what I object to. I don't particularly like having a > new directive in a configuration file which lots of applications read > directly. > > I would rather that a separate configuration file be read, for example, > with a list of shells(5) format files to consult. > > In current, this could be an optional thing, activated in nsswitch.conf, > e.g. make a ports source for shells, and activate it with: > shells: files ports > > or whatever you would like to call the source. Does this capability really need to exist (e.g., supporting many files)? It would seem like the additional complexity would be not what you want for what's essentially a security policy mechansim. Who gets to own these included files? What should their permissions be allowed to be? It doesn't seem unreasonable to have a single file with a list of allowable shells. Is this #include capability going to be added for other files that ports modify such as /etc/master.passwd and /etc/group? I dunno; maybe it's just me, but this really seems like a solution way out of proportion to the "problem" louie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /etc/shells #include syntax support patch
On Sun, Jan 28, 2001 at 10:13:49AM +0100, Steve O'Hara-Smith wrote: > Hi, > > Asbestos suit on, round two. > > The patch below changes getusershell to support a #include syntax > in /etc/shells. I guess this is what I object to. I don't particularly like having a new directive in a configuration file which lots of applications read directly. I would rather that a separate configuration file be read, for example, with a list of shells(5) format files to consult. In current, this could be an optional thing, activated in nsswitch.conf, e.g. make a ports source for shells, and activate it with: shells: files ports or whatever you would like to call the source. -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
/etc/shells #include syntax support patch
Hi,
Asbestos suit on, round two.
The patch below changes getusershell to support a #include syntax
in /etc/shells. It is against RELENG_4 and may require a bit of fiddling
to apply to -current (because of nsdispatch()).
Everything that I can find is using it (well adduser.perl has the
same support written in perl) including sendmail although I cannot see why
sendmail isn't using it's built in fallback code, but it isn't somewhere
I haven't found HASGETUSERSHELL is being set or assumed. I'm not looking
anymore.
The changes are confined to adduser.perl, getusershell.c and shells.
BTW: is there a reason for the avoidance of my in adduser.perl ?
Index: etc/shells
===
RCS file: /home/ncvs/src/etc/shells,v
retrieving revision 1.3.2.1
diff -u -r1.3.2.1 shells
--- etc/shells 2000/07/10 08:47:17 1.3.2.1
+++ etc/shells 2001/01/27 16:32:01
@@ -1,4 +1,4 @@
-# $FreeBSD: src/etc/shells,v 1.3.2.1 2000/07/10 08:47:17 obrien Exp $
+# $FreeBSD: src/etc/shells,v 1.3 1999/08/27 23:23:45 peter Exp $
#
# List of acceptable shells for chpass(1).
# Ftpd will not allow users to connect who are not using
@@ -7,3 +7,4 @@
/bin/sh
/bin/csh
/bin/tcsh
+#include /usr/local/etc/shells
Index: lib/libc/gen/getusershell.c
===
RCS file: /home/ncvs/src/lib/libc/gen/getusershell.c,v
retrieving revision 1.3
diff -u -r1.3 getusershell.c
--- lib/libc/gen/getusershell.c 1999/11/04 04:16:28 1.3
+++ lib/libc/gen/getusershell.c 2001/01/28 08:57:29
@@ -45,6 +45,7 @@
#include
#include
#include
+#include
/*
* Local shells should NOT be added here. They should be added in
@@ -52,8 +53,9 @@
*/
static char *okshells[] = { _PATH_BSHELL, _PATH_CSHELL, NULL };
-static char **curshell, **shells, *strings;
+static char **curshell, **shells;
static char **initshells __P((void));
+static int shellslots = 0;
/*
* Get a list of shells from _PATH_SHELLS, if it exists.
@@ -74,66 +76,87 @@
void
endusershell()
{
-
- if (shells != NULL)
+ char **sp;
+ if (shells != NULL) {
+ for (sp = shells; *sp; sp++) {
+ free (*sp);
+ }
free(shells);
+ }
shells = NULL;
- if (strings != NULL)
- free(strings);
- strings = NULL;
+ shellslots = 0;
curshell = NULL;
}
void
setusershell()
{
-
curshell = initshells();
}
static char **
-initshells()
+readshellfile (char *path)
{
- register char **sp, *cp;
register FILE *fp;
- struct stat statb;
+ static int sp;
+ register char *cp;
+ void *new;
+ char buf[MAXPATHLEN];
+ char *st;
+ int newslots;
- if (shells != NULL)
- free(shells);
- shells = NULL;
- if (strings != NULL)
- free(strings);
- strings = NULL;
- if ((fp = fopen(_PATH_SHELLS, "r")) == NULL)
- return (okshells);
- if (fstat(fileno(fp), &statb) == -1) {
- (void)fclose(fp);
- return (okshells);
- }
- if ((strings = malloc((u_int)statb.st_size)) == NULL) {
- (void)fclose(fp);
- return (okshells);
+ if (shellslots == 0) {
+ sp = 0;
}
- shells = calloc((unsigned)statb.st_size / 3, sizeof (char *));
- if (shells == NULL) {
- (void)fclose(fp);
- free(strings);
- strings = NULL;
- return (okshells);
- }
- sp = shells;
- cp = strings;
- while (fgets(cp, MAXPATHLEN + 1, fp) != NULL) {
+ if ((fp = fopen(path, "r")) == NULL)
+ return (NULL);
+ while (fgets(buf, MAXPATHLEN + 1, fp) != NULL) {
+ cp = buf;
while (*cp != '#' && *cp != '/' && *cp != '\0')
cp++;
- if (*cp == '#' || *cp == '\0')
+ if (*cp == '#' || *cp == '\0') {
+ if (!strncmp (cp, "#include", 8)) {
+ cp++;
+ while (*cp != '#' && *cp != '/' && *cp != '\0')
+ cp++;
+ if (*cp == '/') {
+ char *fn = cp;
+ while (!isspace((unsigned char)*cp) && *cp !=
+'#' && *cp != '\0')
+ cp++;
+ *cp++ = '\0';
+ readshellfile (fn);
+ }
+ }
continue;
- *sp++ = cp;
+ }
+ if (sp >= (shellslots - 1)) {
+ newslots = shellslots ? 2*shellslots : 8;
+ new = re
