Date: Sat, 31 May 1997 10:49:57 -0700 (MST) From: Don Yuniskis <dgy@rtd.com> To: joerg_wunsch@uriah.heep.sax.de Cc: hackers@FreeBSD.ORG Subject: Re: uucp uid's Message-ID: <199705311749.KAA03280@seagull.rtd.com> In-Reply-To: <19970531090733.HH04622@uriah.heep.sax.de> from "J Wunsch" at May 31, 97 09:07:33 am
next in thread | previous in thread | raw e-mail | index | archive | help
Greetings! It seems that J Wunsch said: > As Don Yuniskis wrote: > > > > But that doesn't require distinct UIDs. > > > > How? Since *any* UUCP account can masquerade as another "system" > > and ... > > UUCP account !~= UUCP UID Sorry, I need to be a bit more "precise" on my use of login, uid, etc. (sigh) I guess a good deal of the confusion re: "uid", "login" and "account" is best resolved by example... I'll make a concious effort to try to be clinically correct in my use of "uid", "login" and "account" instead of the informal tone I've been guilty of thus far... A snipette from my /etc/passwd.. uucp:*:66:66:& Administrator:/etc/uucp:/bin/sh nuucp:*:67:67:Local UUCP Access,,,:/var/spool/uucppublic:/usr/libexec/uucp/uucico xuucp:*:67:67:Remote UUCP Access,,,:/var/spool/uucppublic:/usr/libexec/uucp/uucico ufred:*:1101:1101:Fred UUCP Dialin,,,:/var/spool/uucppublic:/usr/libexec/uucp/uucico ubarney:*:1102:1102:Barney UUCP Dialin,,,:/var/spool/uucppublic:/usr/libexec/uucp/uucico uwilma:*:1103:1103:Wilma UUCP Dialin,,,:/var/spool/uucppublic:/usr/libexec/uucp/uucico ubetty:*:1104:1104:Betty UUCP Dialin,,,:/var/spool/uucppublic:/usr/libexec/uucp/uucico upebbles:*:1105:1105:Pebbles UUCP Dialin,,,:/var/spool/uucppublic:/usr/libexec/uucp/uucico ubambam:*:1106:1106:Bam-bam [sic] UUCP Dialin,,,:/var/spool/uucppublic:/usr/libexec/uucp/uucico udino:*:1107:1107:Dino UUCP Dialin,,,:/var/spool/uucppublic:/usr/libexec/uucp/uucico Here, ``uucp'' is the account used for UUCP administration. I login as uucp to manipulate the various configuration files, etc. Note that I've changed the shell and default working directory for this account to be more in line with *this* use of the account (vs. the way FBSD is shipped). All uucp related files are owned by ``uucp''. The ``nuucp'' login is used (by my convention) for "local" UUCP access (i.e. things within my domain, etc.). Also "by convention", the ``xuucp'' login is used for "remote"/external access. Note that this distinction is somewhat arbitrary on my part. These "accounts" represent the most public/permissive form of access. Anyone logging on as ``nuucp'' or ``xuucp'' can masquerade as any other "system" having those permissions. *Currently*, the two logins resolve to the same uid. Note, however, that they have different passwords. So, in the future, I can elect to change the access privileges for the accounts and move them to different uid's without having to contact all xuucp users (for example) and give them a new password as would be the case if nuucp and xuucp shared a common login. Since they share a uid currently, they both *appear* in the logs as ``nuucp'' regardless of the login used to access the system. [side note: I assume that group membership is tied to uid and NOT to login so the group field of /etc/passwd is effectively ignored for the xuucp entry currently?] The ``u<host>'' logins are tailored to individual systems. (While ``U<host>'' was preferable, mail chokes on the uppercase `U'.) They allow me to exercise finer control over which systems access which files, commands, etc. Obviously, another "convention" on my part but I believe pretty widely used. It allows each system to have it's own unique login. It allows me to track resources used by a particular system as well as the activities of that system. It also allows me to change/revoke those priviledges if a problem develops with a particular "account" without affecting any other UUCP "accounts". Did *that* clarify my use of logins, uids, accounts, etc.? :> > Where !~= translates into ``not necessarily equal''. You can track of > the different accounts even if they have the same UID. As i wrote > earlier, the only thing that is recording by UID is the process And the basic access control mechanisms inherent in UN*X. You can, for example, create another copy of uucico that doesn't suid(uucp) but, rather, runs under the access controls of the invoking user to allow the kernel to enforce the access control privileges on a per user (i.e. per *uid*) basis. > accounting system. Things like utmp/wtmp work by login name, and i > think Taylor's possibility to limit a particular system name to a > distinct account, too (though i've never been using this). Yes, but this relies on the system on the other end "behaving". A user could hack up a UUPC (vs. UUCP) box and pretend to be any system he wants to be... So, if a single login is shared, any user can pretend to be any *system* with that login -- in spite of Taylor's hooks. --don
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199705311749.KAA03280>