Date: Mon, 23 Dec 1996 18:46:57 +1100 (EST) From: David Nugent <davidn@sdev.usn.blaze.net.au> To: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7=2C_Andrey_Chernov?= <ache@nagual.ru> Cc: freebsd-current@freebsd.org Subject: Re: Confused about locale Message-ID: <Pine.BSF.3.95.961223182350.18389Q-100000@sdev.usn.blaze.net.au> In-Reply-To: <Pine.BSF.3.95.961223092559.656A-100000@nagual.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 23 Dec 1996, [KOI8-R] Андрей Чернов, Andrey Chernov wrote: >> The user can, by overriding the standard environment variables in >> his or her .login or .profile, just as they do now. The only >> thing the lang= and charset= entries in the login class affects >> are the defaults set by login in the user's environment. Editing >> startup files is no more difficult than running, say, chpass et >> al. > >Excepting one small thing: command interpreter itself started >with system locale, not user defined one and user can change it >only later (if ever can!). Will "exec $SHELL" at the end of .profile solve this at all? Yes, I know it is a kludge. :) The other thing is that login.conf (BSDI's anyway, and no doubt ours when we get to implement it) will provide a way of execing an alternate program instead of a shell when the user logs in, but $SHELL is still set as per the passwd->pw_dir field. It would be a very simple matter to have this alternate pick up a $HOME/.language file or similar, then exec the shell as a login shell (as an alternate may have to do anyway). >Shell f.e. understand on-the-fly locale changes >only very recently (my fix). Yes, I understand that problem well enough. ;) >> Not at all. Only that "class" is a pointer to /many/ parameters >> that (1) set administrative restrictions and (2) sets up the >> *default* login environment for a set of users. For a shell >> account, most of the environment setup remains changeable, just >> as it is now. > >Why not use "tc=" modifier to point to default class? >I.e. example entry will looks like: > >la=ru_SU.KOI8-R:ch=KOI8-R:tc=def_class That's precisely how /etc/login.conf is formatted, yes. And a typical setup will involve a bunch of top-level defaults together with tc= entries to string them together. But this doesn't solve the user being able to modify them. [Pie in the sky idea] what could be done is to read $HOME/.login.env (name is only a suggestion) to pick up these things, but only *after* the setuid()/initgroups(), and with only some subset of keywords allowed in user mode. Some, like setting max-rlimits, only have meaning if running as root anyway. That would at least close all of the main holes and means of circumventing administrative policy this might otherwise allow. This doesn't much appeal to my sense of asthetics though, but it is similar to .termcap style user-configuration. Comments? [Incidently, getcap(3) doesn't have termcap's liminations with respect to two character identifiers - fortunately. :-) Files tend to be a lot more readable that way.] Regards, David Nugent - Unique Computing Pty Ltd - Melbourne, Australia Voice +61-3-9791-9547 Data/BBS +61-3-9792-3507 3:632/348@fidonet davidn@freefall.org davidn@blaze.net.au http://www.blaze.net.au/~davidn/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.961223182350.18389Q-100000>