Date: Tue, 29 Apr 1997 17:13:55 +1000 From: David Nugent <davidn@labs.usn.blaze.net.au> To: David Dawes <dawes@rf900.physics.usyd.edu.au> Cc: hackers@xfree86.org, freebsd-hackers@freebsd.org Subject: Re: xdm in /usr/X11R6/etc/rc.d problem Message-ID: <199704290713.RAA29511@labs.usn.blaze.net.au> In-Reply-To: Your message of "Mon, 28 Apr 1997 17:02:04 %2B1000." <19970428170203.28285@rf900.physics.usyd.edu.au>
next in thread | previous in thread | raw e-mail | index | archive | help
> I have no idea. I don't recall seeing any patches for this being > submitted to us at XFree86.Org. I don't have any machines running > -current at the moment. Ok. I thought I saw some comment that some "basic" support had been added, but perhaps not. This would be fairly easy to do, so I'll send diffs<tm> as soon as I can make some time. Basically all that's needed is to change setlogin()/setuid()/initgroups() to a setusercontext() call, but depending on the environment this can get kind of hairy. setusercontext() does all sorts of things in addition to that, including setting resource limits and system, umask and user-defined environment settings (and soon, user-defined resource limits, within the administrative hard limits). > I'd also like to see something that allows us to remove the direct > utmp/wtmp manipulation from xdm and xterm. Well, even if the wtmp/utmp format is not revised today as we've tentatively planned in FreeBSD, there's no reason why we can't at least provide an API. What about something like this: /* update a tty slot */ updateutmp(const char *line, const char *name, const char *host); line - required, tty name - username, NULL or empty string host - hostname/ip, NULL or empty string Then an iteration interface, a la getpwent(): int setutmpent(void); struct xutmp *getutmpent(void); struct xutmp *getutmptty(const char *line); void endutmpent(void); struct xutmp is an "extended utmp" struct that contains no fixed arrays, but uses pointers instead. For the time being, we can do the utmp -> xutmp 'translation', including NUL termination, as part of the API. Later on, whenever the format is changed, it won't matter at all to application code. I'm not sure how much call there is for additional information to be stored in utmp, but if so, then a similar approach to below could be used. The above does assume a BSD environment though, and omits the SYSV style "type" and inittab "id" fields, so perhaps we should work those in (obviously, they'll get ignored by BSD). struct xutmp would not necessarily have to be platform independant provided that the 'common' fields are similarly named (unlike now!). /* add a record to wtmp */ updatewtmp(const char *line, const char *name, const char *host, struct wtmpx *xinfo); line, name, host as above xinfo - Additional information, as yet to be determined or NULL if none. utmp.h should define this as a simple pointer type with a "type" member as its first element, and (perhaps) a "struct wtmpx *next" as its next element, if we wanted to daisy-chain additional blocks of information. Valid "types" would be #defines in utmp.h, so its easy to detect (in source code) what extensions a system does/does not understand. Additions, changes, corrections, suggestions? David Nugent - Unique Computing Pty Ltd - Melbourne, Australia Voice +61-3-9791-9547 Data/BBS +61-3-9792-3507 3:632/348@fidonet davidn@freebsd.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?199704290713.RAA29511>