dv@uswnvg.UUCP (Dan Volkman) (02/22/91)
Being a system administrator on a large 5.3.X unix production shop, I am continually confronted with situations that demand a change in an individuals group status. Someone on group "a" that mostly uses applications belonging to that group has a need to occasionly use group "b"s applications. Most of these users are in a captured menu type environment and the concept of shells and processes are foreign to them so the att command "newgrp" is not a possible solution. We created a sgid program "asgroup" to solve this problem but I feel that once the permission has been granted with an entry in /etc/group, this kind of activity should be handled seemlessly by the kernel. I know that BSD did such a modification but I do not see this feature in the 5.4 documentation. With the "newgrp" command, a user can function under group "a" or "newgrp b" then function under group "b" but he can not function in both group "a" and "b" even though that permission has been granted. As a side note, we also discovered that if a group definition line in /etc/group exceeds BUFSIZ serious obstacles appear. It appears that the "getgr..." functions do not allow a continuation character (I think they are using "fgets".). dv@uswnvg
jfh@rpp386.cactus.org (John F Haugh II) (02/23/91)
In article <654@uswnvg.UUCP> dv@uswnvg.UUCP (Dan Volkman) writes: > As a side note, we also discovered >that if a group definition line in /etc/group exceeds BUFSIZ serious >obstacles appear. It appears that the "getgr..." functions do not >allow a continuation character (I think they are using "fgets".). Yes, this seems to be the case. Also, there are serious obstacles to editors with very long lines. This system, vi for example, seems incapable of editing files with lines longer than 4KB. The solution is to permit the "\" character to function as a line continuation character on input, and add "\" characters on output. The /etc/group file, if put into DBM format, has a similiar transformation made - each record should be re-blocked into some number of smaller records which will be re-assembled on input, and re-created on output. These changes have been made in the next release of the shadow login system myself and various netters have been working on. -- John F. Haugh II UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 832-8832 Domain: jfh@rpp386.cactus.org "I've never written a device driver, but I have written a device driver manual" -- Robert Hartman, IDE Corp.
guy@auspex.auspex.com (Guy Harris) (02/24/91)
>We created a sgid program "asgroup" to solve this problem but I >feel that once the permission has been granted with an entry in /etc/group, >this kind of activity should be handled seemlessly by the kernel. >I know that BSD did such a modification but I do not see this feature >in the 5.4 documentation. Umm, at least at the kernel level, it *is* in System V Release 4 (you did say "5.4 documentation", not "5.3.x documentation"). Dunno if they've set "login" up to call "initgroups()" or not, though, so while it may be in the kernel, it may not be there in a sufficiently convenient form....
ag@amix.commodore.com (Keith Gabryelski) (02/25/91)
In article <19069@rpp386.cactus.org> jfh@rpp386.cactus.org (John F Haugh II) writes: >[...] Also, there are serious obstacles to editors with very long >lines. This system, vi for example, seems incapable of editing files >with lines longer than 4KB. > >The solution is to permit the "\" character to function as a line >continuation character on input, and add "\" characters on output. A more general solution is to fix the bug that prevents the program from correctly dealing with sufficiently long lines. Pax, Keith Ps, This is not to say that line continuation characters are evil but they should be unnecessary. -- "[...] a POSIX implementation that | Keith Gabryelski returns errors for practially every| Amiga Unix Software Development operation is conformant (useless, | ag@amix.commodore.com but conformant)." -- Chris Torek| ...!cbmvax!amix!ag
jfh@rpp386.cactus.org (John F Haugh II) (02/25/91)
In article <1183@amix.commodore.com> ag@amix.commodore.com (Keith Gabryelski) writes: >In article <19069@rpp386.cactus.org> jfh@rpp386.cactus.org (John F Haugh II) >>The solution is to permit the "\" character to function as a line >>continuation character on input, and add "\" characters on output. > >A more general solution is to fix the bug that prevents the program >from correctly dealing with sufficiently long lines. Agreed. However, this has a dependency on fixing every program which might ever have anything to do with text files. It isn't just that getgrent() can't handle arbitrary length lines - but neither can a whole slew of other commands that don't rely on getgrent() for their input. >Ps, This is not to say that line continuation characters are evil but >they should be unnecessary. Regrettably they are quite necessary because so many other UNIX commands don't properly handle lines of arbitrary length. ;-( -- John F. Haugh II UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 832-8832 Domain: jfh@rpp386.cactus.org "I've never written a device driver, but I have written a device driver manual" -- Robert Hartman, IDE Corp.