Date: Thu, 27 Jan 2005 16:27:23 +0100 (CET) From: Barry Bouwsma <freebsd-misuser@remove-NOSPAM-to-reply.NOSPAM.dyndns.dk> To: FreeBSD Barnyard and Stable <freebsd-stable@freebsd.org> Cc: Julian Elischer <julian@elischer.org> Subject: Re: update for 4.11 Security Officer-supported branches Message-ID: <200501271527.j0RFRML1000998@Mail.NOSPAM.DynDNS.dK> References: <1105317580.22779.12.camel@wednesday.pricegrabber.com> <20050110132233.GA5374@lum.celabo.org> <41E2D492.9020302@elischer.org> <200501121456.j0CEu3J2088923@Mail.NOSPAM.DynDNS.dK> <41E57E85.5040102@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[sorry for the delay in this reply; I can't remember if I already
sent a response...]
On Wed, 12 Jan 2005 11:46:13 -0800, Julian Elischer wrote:
> >>While a 4.12 will PROBABLY not happen, I do plan on continued MFCs of
> >>important
> >>changes to RELENG_4 as I do not envision my custommers moving to 5.x
> >Thanks, Julian, and I'd like to contemplate getting a few of my MFC
> >One of these things I've found very handy is the `mount' option
> >introduced in 5.x that allows one to specify with -F an alternate
> >to /etc/fstab to be used.
> we can probably MFC anything that doesn't break any existing ABI.
I'll plead ignorance and stupidity. Would an ABI change be something
like what I needed to do in another project, changing
- int (* seek) (data_source_t *source, long offset, int whence);
+ int (* seek) (data_source_t *source, ogg_int64_t offset, int whence);
in order to fix largefile support, when this is something expected
to be called by userland programs? I'll guess yes.
> >In order to adopt this change, I had to add to libc in 4.x as well
> >as butcher the `mount' code. Does such a change stand a chance of
> >being added to 4.x, or are infrastructure changes required this way,
> >like to libc, off-limits outside my own hive of personal hackery?
> libc is not usually a target in a legacy branch. Addign a new function to it
> may be ok in some cases but probably best to not do it.
I'll leave the call to you, or anyone else who knows better than I.
As far as I know, it's not easily possible to implement the `-F' mount
option without this libc change, but I haven't played with it as a MFC
did the job for me. The diff below is based on what was -current when
this option was introduced, and is fairly clean, as follows -- the diff
needed for `mount' itself would follow later, if this diff to RELENG_4
libc does not raise serious objections:
--- /stand/FreeBSD4-src/source-hacks/lib/libc/gen/fstab.c-ORIG Fri Jan 28 00:06:15 2000
+++ /stand/FreeBSD4-src/source-hacks/lib/libc/gen/fstab.c Tue Jul 27 10:30:39 2004
@@ -57,11 +57,40 @@
static FILE *_fs_fp;
static struct fstab _fs_fstab;
static int LineNo = 0;
+static char *path_fstab;
+static char fstab_path[PATH_MAX];
+static int fsp_set = 0;
static void error __P((int));
static void fixfsfile __P((void));
static int fstabscan __P((void));
+void
+setfstab(const char *file)
+{
+
+ if (file == NULL) {
+ path_fstab = _PATH_FSTAB;
+ } else {
+ strncpy(fstab_path, file, PATH_MAX);
+ fstab_path[PATH_MAX - 1] = '\0';
+ path_fstab = fstab_path;
+ }
+ fsp_set = 1;
+
+ return;
+}
+
+const char *
+getfstab (void)
+{
+
+ if (fsp_set)
+ return (path_fstab);
+ else
+ return (_PATH_FSTAB);
+}
+
static void
fixfsfile()
{
@@ -229,7 +258,13 @@
LineNo = 0;
return(1);
}
- if ((_fs_fp = fopen(_PATH_FSTAB, "r")) != NULL) {
+ if (fsp_set == 0) {
+ if (issetugid())
+ setfstab(NULL);
+ else
+ setfstab(getenv("PATH_FSTAB"));
+ }
+ if ((_fs_fp = fopen(path_fstab, "r")) != NULL) {
LineNo = 0;
return(1);
}
@@ -244,6 +279,8 @@
(void)fclose(_fs_fp);
_fs_fp = NULL;
}
+
+ fsp_set = 0;
}
static void
@@ -254,7 +291,7 @@
char num[30];
(void)_write(STDERR_FILENO, "fstab: ", 7);
- (void)_write(STDERR_FILENO, _PATH_FSTAB, sizeof(_PATH_FSTAB) - 1);
+ (void)_write(STDERR_FILENO, path_fstab, strlen(path_fstab));
(void)_write(STDERR_FILENO, ":", 1);
sprintf(num, "%d: ", LineNo);
(void)_write(STDERR_FILENO, num, strlen(num));
I'm pretty sure (but not positive) that these diffs do not have
tentacles afflicting other code, and should be safe to apply to a
virginal RELENG_4 system without major breakage.
thanks
barry bouwsma
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200501271527.j0RFRML1000998>