On Mon, Oct 01, 2001 at 11:51:32AM -0600, Lyndon Nerenberg wrote: > >>>>> "Ruslan" == Ruslan Ermilov <[EMAIL PROTECTED]> writes: > > Ruslan> It doesn't really matter what the home directory is set to > Ruslan> (IIRC), but the shell must be uucico(8). > > No, this is wrong on both counts. > > By convention, the home directory of the uucp login has corresponded > to the UUCP PUBDIR. Traditionally this was /usr/spool/uucppublic, and > maps to /var/spool/uucppublic these days. Thus, if I wanted to > copy a file to the public file area on machine b I would incant > > uucp file b!~ > > and the uucico on the remote end would expand the '~' to > /usr/spool/uucppublic. > Of course I know what the /var/spool/uucppublic is for, but it's not controlled by "uucp" account in FreeBSD. It's controlled by the "pubdir" UUCP config option, that's why "it doesn't really matter".
> This usage predates (and probably inspired) the common behavior of > current shells handling of '~' expansion. While no modern UUCP I'm > aware of uses the value of pw->pw_dir to derive PUBDIR, POLA would > imply that the interpretation of '~uucp' should be the same for > both the uucp(1) command and for shells that do ~ expansion. Therefore > I would recommend keeping the UUCP home directory as /var/spool/uucppublic. > If you want to be paranoid you make this directory owned by root.wheel > and mode 0555 without breaking anything. > The problem is that "uucp" account should stay, but the creation of this directory should be moved to ports. And we don't want "uucp" account with non-existing homedir. > As for the `uucp' account's shell, this should be set to > /sbin/nologin. The purpose of the uucp entry in /etc/passwd is to > provide a unique runtime uid for the setuid UUCP components. Note that > there are some periodic maintenance scripts that should be run if you > actively use UUCP. These traditionally run under the `uucp' identity, > so you need to make sure that they will continue to function with > /sbin/nologin. (Which they should, otherwise they would have barfed > with uucico as the shell.) The shell for the uucp account should most > certainly NOT be uucico! And you should *never* allow remote site UUCP > logins (those that run uucico) under the `uucp' login, for obvious > security reasons. Instead, create seperate unique logins for each > remote site, just as you would for each of your shell accounts, but > set the login shell to uucico. > Oh, you obviously replied too quickly. This is exactly what I wrote in my email. I just tried to explain "historical behavior" at the start of my message, and you were confused by not reading my mail entirely. Cheers, -- Ruslan Ermilov Oracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
