schriste@uceng.UC.EDU (Steven V. Christensen) (04/10/90)
We have a network of various types of Suns, which graduate and undergrads use. We would like to implement automatic notification of various things when a user logs in, ala .login file. We have thought about adding a line "source master_login_file" as the first line in the user .login, but this could be changed by the user, and he/she will miss this notification. Can anyone point me to a login.c replacement which causes a global .login file to be executed first? I assume I would place a "source ~/.login" as the last line of this global file. Thanks, Steven -- Steven V. Christensen U.C. College of Eng. schriste@uceng.uc.edu
tholo@barsoom.nhh.no (Thorsten Lockert) (04/11/90)
schriste@uceng.UC.EDU (Steven V. Christensen) writes: >Can anyone point me to a login.c replacement which causes a global >.login file to be executed first? I assume I would place a "source ~/.login" >as the last line of this global file. Um, wont't /etc/profile and/or /etc/cshrc do that right now?
vlb@Apple.COM (Vicki Brown) (04/11/90)
In article <780@barsoom.nhh.no> tholo@barsoom.nhh.no (Thorsten Lockert) writes: >schriste@uceng.UC.EDU (Steven V. Christensen) writes: >>Can anyone point me to a login.c replacement which causes a global >>.login file to be executed first? I assume I would place a "source ~/.login" >>as the last line of this global file. > >Um, wont't /etc/profile and/or /etc/cshrc do that right now? Unfortunately, /etc/cshrc is not standard (it is not in BSD 4.3 and it does not appear to be in SunOS 4.0). On A/UX, the sources indicate that /etc/cshrc is derived originally from UniSoft. It would also appear that /etc/profile is not standard either. My personal inclination is to lean towards using a standard .login/.profile somewhere, setting up new users accounts to source this file, and including comments to tell them why they want to. (I've never liked sysadmins who force me to do something.) What, precisely, are you doing for these people that you must force it to be done? Can't you explain why they don't want to edit things away? If you are only looking for notification (rather than variable setting and the like), why not /etc/motd? -- Vicki Brown (408) 974-2120 A/UX Engineering vlb@apple.com all opinions are mine (but I'm willing to share :-)
apippin@polyslo.CalPoly.EDU (Pinhead@Spikes) (04/11/90)
Add then schriste@uceng.UC.EDU (Steven V. Christensen) babbles...
~Can anyone point me to a login.c replacement which causes a global
~.login file to be executed first? I assume I would place a "source ~/.login"
~as the last line of this global file.
I agree that the message of the day should suffice. If you
really want to force this...
Put a file ~/.login with owner root and mode 644. The last
line should source ~/.userlogin, if it exists.
aBp.
--
Andy Pippin -*- apippin@polyslo.CalPoly.EDU -*- Conserve water, drink bier.erlkonig@walt.cc.utexas.edu (Christopher North-Keys) (04/11/90)
THE FOLLOWING CONTAINS A REASONABLY TIDY, BUT TOTALLY UNSUPPORTED HACK TO THE SYSTEM LOGIN COMMAND. SINCE NO SYSTEM'S CONFIGURATION CAN BE FULLY ANTICIPATED, NOTE THAT EVEN DOING THE BELOW CORRECTLY MAY DISABLE ALL LOGINS TO YOUR SYSTEM, OR WORSE. IT MIGHT BE GOOD TO HAVE INSTALLATION TAPES ON HAND WHILE EXPERIMENTING... schriste@uceng.UC.EDU (Steven V. Christensen) writes: > Can anyone point me to a login.c replacement ... when looking for a way to have a notice, etc., read by all users. Steve and several of those replying immediately began discussing /etc/motd, ~/.cshrc, /etc/cshrc, ~/.profile, etc. None of these remotely answer the problem. A user can turn off /etc/motd viewing for him/herself with ~/.hushlogin, and the various startup scripts only apply to their specific interpreters, most of which have a different syntax. (Do *you* know the command syntax for the "ish" shell? No, I don't either...) What is needed is a way to specify a *program* for login to run as each user logs in. Currently on /usr/ucb/quota appears to be used this way. So... backup your login program and do the following (after backup it up): (Have you backed up your login first?) Whip out your GNUEmacs or other binary-capable editor; note that this generally does *not* include VI. Load in the login program *executable* for editing. Notice the /usr/ucb/quota string with the binary. This string is the argument to a call to run another program. Warnings: Do NOT alter the length of the binary. Do NOT try to replace /usr/ucb/quota with a longer pathname. Do NOT put in a path to a script, it would be *very* insecure. Replace the existing path with the new path of the same length or less, padding any leftover space with zeros. Be very careful to exactly match the length of the original path with the sum of the new pathlength and trailing zeros. A program path like /usr/etc/logex might be appropriate (this assumes that the path /usr/ucb/quota was actually used on your system; BE WARNED). The resulting file, once saved, will contain a hook which can be filled with virtually any utility. Examples: A program putting up a banner from a network-wide file, in addition to the local /etc/motd (Steve's problem). A program performing additional accounting or administrative tasks. A program to notify an administrator in real time of the login, or other security-related job. Additional check: compare the sizes of the original and new login executables with "wc" or equivalent. They must be equal. Be particularly careful of creating new security holes. as login is usually set-UID root. Thus no user should be able to effect the added program's activity. ------ It would have been nice if login read a file on startup for additional administrative programs to run, instead of hard-wiring /usr/ucb/quotas. Good luck. Don't screw up and lock yourself out of your system. Remember you can test the new one by executing it by ./login or the equivalent (csh traps the simple token "login". and performs an exec.) Don't install it carelessly. ------------------------------------/\---------------------------------------- Seo: Harp[@Mcc.Com] / \/\ ^*^ Christopher North-Keys Tha mi gu trang a'cluich. / \ \ Assoc. Systems Analyst, MCC --------------------------------(disclaimer)----------------------------------
drich@dialogic.com (Dan Rich) (04/11/90)
In article <4147@uceng.UC.EDU> schriste@uceng.UC.EDU (Steven V. Christensen) writes: > Can anyone point me to a login.c replacement which causes a global > .login file to be executed first? I assume I would place a "source ~/.login" > as the last line of this global file. Everyone seems to be asking "Why?" to this question, but there is a host of reasons to do this. Actually, most of the reasons I have run into are more appropriate for a "group" login, but a system login can do many of the same things. At the University I attended, they would put a: source GROUP/.login in our .login files, where GROUP was replaced with our group library. This was do to give us access to local (class) libraries, and to give us access to software that was not accessable to other classes. Here at Dialogic we use the System V /etc/profile to define our global paths, display the system news, and define global aliases. Without the /etc/profile, we would have to add all of this to each individual .profile. Not only is this a waste of disk space, but in my experience, users have a tendency to remove anything that they don't immediately recognize from their .profiles. -- Dan Rich | ARPA: drich@dialogic.com UNIX Systems Administrator | UUCP: uunet!dialogic!drich Dialogic Corporation | - Quis custodiet ipsos custodes - (201) 334-1268 x213 | - Who watches the watchmen? -
jeff@quark.WV.TEK.COM (Jeff Beadles) (04/11/90)
apippin@polyslo.CalPoly.EDU (Pinhead@Spikes) incorrectly states: >Add then schriste@uceng.UC.EDU (Steven V. Christensen) babbles... >>Can anyone point me to a login.c replacement which causes a global >>.login file to be executed first? I assume I would place a "source ~/.login" >>as the last line of this global file. > I agree that the message of the day should suffice. If you > really want to force this... > Put a file ~/.login with owner root and mode 644. The last > line should source ~/.userlogin, if it exists. Bleep. Wrong answer. If the user owns h{is,er} home directory, they could easily do away with the ~/.login, regardless of the permissions. If you can't figure out how, then see comp.unix.questions. It's not a wizard level question . :-) Also, some versions of csh do NOT source ~/.{login,cshrc} unless it's owned by the user spawning the shell. Adding the functionality to csh to "source" a /etc/login is trivial. I don't know why it hasn't been added as /etc/profile has been to /bin/sh. -Jeff -- Jeff Beadles jeff@quark.WV.TEK.COM Utek Engineering, Tektronix Inc. +1 503 685 2568 "Credo quia absurdum"
richard@aiai.ed.ac.uk (Richard Tobin) (04/12/90)
In article <28003@ut-emx.UUCP> erlkonig@walt.cc.utexas.edu (Christopher North-Keys) writes: >Load in the login program *executable* for editing. >Notice the /usr/ucb/quota string with the binary. >Replace the existing path with the new path of the same length or less Why not just replace the *file* /usr/ucb/quota with one that does what you want? -- Richard -- Richard Tobin, JANET: R.Tobin@uk.ac.ed AI Applications Institute, ARPA: R.Tobin%uk.ac.ed@nsfnet-relay.ac.uk Edinburgh University. UUCP: ...!ukc!ed.ac.uk!R.Tobin
bitbug@lonewolf.sun.com (James Buster) (04/12/90)
In article <DRICH.90Apr11111533@testbox.dialogic.com> drich@dialogic.com (Dan Rich) writes: >Not only is this a waste of disk space, but in my >experience, users have a tendency to remove anything that they don't >immediately recognize from their .profiles. Of course. Anything that I didn't put in my .profile is a security problem. At the very least, things that I didn't add impede desired customizations. -- --------------------------------------------------------------------- James Buster (Domain) bitbug@lonewolf.ebay.sun.com Mad Hacker Extraordinaire (UUCP) ...!sun.com!lonewolf!bitbug ---------------------------------------------------------------------
guy@auspex.auspex.com (Guy Harris) (04/12/90)
>>Um, wont't /etc/profile and/or /etc/cshrc do that right now? > >Unfortunately, /etc/cshrc is not standard (it is not in BSD 4.3 and it does not >appear to be in SunOS 4.0). It doesn't appear to be there because it isn't there. I think some systems may support it, but with a different name; I seem to remember that HP-UX supports it, but it may be called something else. I think AT&T picked up that feature in the S5R4 C shell, perhaps with the HP-UX name.... >It would also appear that /etc/profile is not standard either. It's largely standard on systems with System III or later Bourne shells (except, I think, some SunOS releases between 3.0 and either 3.2 or 4.0). However, some systems with older Bourne shells exist, so it's not universal.
jgreco@archimedes.math.uwm.edu (Joe Greco) (04/12/90)
In comp.unix.wizards article <40193@apple.Apple.COM>, vlb@Apple.COM (Vicki Brown) wrote: :My personal inclination is to lean towards using a standard .login/.profile :somewhere, setting up new users accounts to source this file, and including :comments to tell them why they want to. (I've never liked sysadmins who force :me to do something.) What, precisely, are you doing for these people that :you must force it to be done? Can't you explain why they don't want to edit :things away? Besides, there isn't a heck of a lot that you can do in a cshrc that cannot be undone on the command line. Generally users do not seem to change things in their .cshrc files that they do not understand. This applies to about 90% of the users on this site. Anybody knowledgeable enough to want to change whatever it is that you want to put in it probably knows why you did it and why they should want to do otherwise. ... Joe
lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) (04/12/90)
In article <28003@ut-emx.UUCP> erlkonig@walt.cc.utexas.edu (Christopher North-Keys) writes:
: What is needed is a way to specify a *program* for login to run as each user
: logs in. Currently on /usr/ucb/quota appears to be used this way. So...
: backup your login program and do the following (after backup it up):
:
: (Have you backed up your login first?)
:
: Whip out your GNUEmacs or other binary-capable editor; note that this
: generally does *not* include VI.
:
: Load in the login program *executable* for editing.
:
: Notice the /usr/ucb/quota string with the binary. This string is the
: argument to a call to run another program.
:
: Warnings: Do NOT alter the length of the binary.
: Do NOT try to replace /usr/ucb/quota with a longer pathname.
: Do NOT put in a path to a script, it would be *very* insecure.
:
: Replace the existing path with the new path of the same length or less, padding
: any leftover space with zeros. Be very careful to exactly match the length
: of the original path with the sum of the new pathlength and trailing zeros.
:
: A program path like /usr/etc/logex might be appropriate (this assumes that
: the path /usr/ucb/quota was actually used on your system; BE WARNED).
:
: The resulting file, once saved, will contain a hook which can be filled with
: virtually any utility.
Or just say
perl -pi.bak -e 's:/usr/bin/quota:/usr/etc/logex:' /bin/login
Larry Wall
lwall@jpl-devvax.jpl.nasa.govbph@buengc.BU.EDU (Blair P. Houghton) (04/12/90)
In article <262284c4.2013@petunia.CalPoly.EDU> apippin@polyslo.CalPoly.EDU (Pinhead@Spikes) writes: > >Add then schriste@uceng.UC.EDU (Steven V. Christensen) babbles... >~Can anyone point me to a login.c replacement which causes a global >~.login file to be executed first? I assume I would place a "source ~/.login" >~as the last line of this global file. > > Put a file ~/.login with owner root and mode 644. The last > line should source ~/.userlogin, if it exists. Then the user does rm .login and unless root owns his home directory, it's gone. You'd have to have root own his home directory. You could create a subdirectory owned by the user for the user's files. Then you could maybe write a setuid-root C program that allows the user to write files into the root-owned home directory, but not overwriting the .login file. --Blair "Or you could give them the root password..."
) (04/12/90)
Unless you want them to be able to remove the system .login (ie. give them flexability)... (shhhh...I know, we're not supposed to talk about users who know what they're doing...after all, they might turn into.. <shutter> unix wizards) John :)
apippin@polyslo.CalPoly.EDU (Pinhead@Spikes) (04/12/90)
~apippin@polyslo.CalPoly.EDU (Pinhead@Spikes) writes:
~> Put a file ~/.login with owner root and mode 644. The last
~> line should source ~/.userlogin, if it exists.
Add then bph@buengc.bu.edu (Blair P. Houghton) babbles...
~Then the user does
~ rm .login
~and unless root owns his home directory, it's gone.
Sigh. Yes, I realize this now. This will be my last posting
in this group for a while. I have been offered a chance to
commit seppuku (sp?) and will take the chance to regain my
honor after f*cking up on my first post here.
Sheesh...
aBp.
--
Andy Pippin -*- apippin@polyslo.CalPoly.EDU -*- Conserve water, drink bier.johnson@ncrons.StPaul.NCR.COM (Wayne D. Johnson) (04/13/90)
In article <780@barsoom.nhh.no> tholo@barsoom.nhh.no (Thorsten Lockert) writes: >Um, wont't /etc/profile and/or /etc/cshrc do that right now? Hmmm. My Sun dons't seem to support /etc/cshrc. Is there some trick to using it or are there different versions of csh around? I would love to have somthing like this. I have been seriously tempted in banning csh on my system because everyone has to maintain their own .cshrc. -- Wayne Johnson | Is a baby's life worth more than the right to NCR Comten, Inc. | make a choice? Babies are people too. Roseville MN 55113 +----------------------------------------------------- (Voice) 612-638-7665 (E-MAIL) W.Johnson@StPaul.NCR.COM
venta@i2ack.sublink.org (Paolo Ventafridda) (04/13/90)
>In article <780@barsoom.nhh.no> tholo@barsoom.nhh.no (Thorsten Lockert) writes: >>schriste@uceng.UC.EDU (Steven V. Christensen) writes: >>>Can anyone point me to a login.c replacement which causes a global >>>.login file to be executed first? I assume I would place a "source ~/.login" >>>as the last line of this global file. >> What's wrong with putting a custom program in place of /bin/sh (or whatever) inside /etc/passwd ? All this program has to do is executing the shell as usual, at the end of its job. Am i missing the point? Sorry if so. Paolo -- Paolo Ventafridda - Milano, ITALY | INTERNET: venta@i2ack.SUBLINK.ORG
guy@auspex.auspex.com (Guy Harris) (04/15/90)
>What's wrong with putting a custom program in place of /bin/sh (or >whatever) inside /etc/passwd ? >All this program has to do is executing the shell as usual, at the >end of its job. Am i missing the point? Sorry if so. Be careful, because this can have unfortunate side effects. For instance, programs that either look at the SHELL environment variable, or at the "pw_shell" entry in your password file, to figure out what shell to use when they fire off a subshell will run your custom program. This means, for instance, that if you're running under a window system like SunView or X, every terminal emulator you fire up will use that custom program as your shell. If your custom program assumes that it's only run as a login shell, things may not work the way you expect them to.... In other words, your program should probably look at "argv[0]" to see if it begins with "-", just as the shells do, and use that to decide whether it's a login shell or not, if there's anything it'd do only as a login shell, not a subshell. Alternatively, it could modify the environment to set SHELL to your real shell before running your shell (although it should still check "argv[0]", so that it knows whether to run your real shell with a name beginning with "-" or not).