On 19 Aug 2012, at 13:33, Jilles Tjoelker <jil...@stack.nl> wrote: > On Sat, Aug 11, 2012 at 09:05:44PM +0200, Dag-Erling Smørgrav wrote: >> "Simon L. B. Nielsen" <si...@freebsd.org> writes: >>> This has been discussed a number of time, but there are no nice and >>> simple solution. > >> There is a simple solution that, while not bulletproof, would work well >> enough in most cases: have 'make installworld' create /etc/issue, which >> would look like this: > >> FreeBSD 9.0-RELEASE-p4 amd64/amd64 > > I think the idea of having 'make installworld' create something is good, > but we should not hard-code policy by writing the information into a > file that may be shown to unauthenticated users (such as by getty). > > A new file with a name=value format somewhat like /etc/lsb-release on > Linux seems more appropriate. If the admin wants /etc/issue, > /etc/rc.d/motd can create it. > > The new file is not a configuration file and tools like mergemaster and > freebsd-update must not bother the admin about it. If all files under > /etc are considered "configuration files", then perhaps a different > location is better.
/etc is IMO generally expected to be managed by mergemaster etc. so I think that's a bad location for an authoritative file. Having thought about this for a while, my preference is to have the file with the information somewhere under /usr and be installed with a normal installworld. That has the highest likelihood to actually matching the rest of the userland IMO, for cases like shares /usr etc (though that's probably less common now). If it's a text file it should probably be under /usr/share somewhere. If it's a binary /usr/bin or possibly /usr/libexec if more magic is made to hide it. The part I'm not yet really sure about is how to display this information. For the freebsd-update case of userland update only, it's possible we can do something sane and preserve our existing simple uname based output, but I'm not sure. I haven't gone through all the different cases to be sure. For the installworld case I'm even less sure we can simple and sanely do the right thing considering how to handle cases with kernel and userland seriously out of sync. A simple approach would be to just append -uX to the uname string, but I'm not really sure if I like that... To ilustrate, if for a 9.0 system, where kernel is patch 3 userland is patch 5, we would show FreeBSD 9.0-RELEASE-p3-u5. The nice thing is that we don't try to be clever and therefor are less likely to get it wrong. More fancy things with creating log files etc. does really solve the issue at hand with getting the running patch level in a simple way IMO. PS. /etc/issue sounds like a file which certainly shouldn't contain authoritative info, but if it exists should rather be generated like /etc/motd. -- Simon L. B. Nielsen _______________________________________________ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
