lyman@3bee2.UUCP (William S. Lyman Jr.) (05/12/88)
H E L P !!! I am running the News software for Usenet and when it goes to create a directory for the new group it is not what I defined it for in local- ize.sh it is making them Owner root Grp root. Thenit can't write the articial and throws it in junk. I have tried this on my 3b2 and 7300. It is probably simple. I'm just screwing something up yes? ****************************************************************** William S. Lyman Jr. AT&T MAIL wmlyman or 3bee2!lyman Suite #167 USENET yale!spock!blyman P.O. Box 1019 yale!spock!3bee2!lyman Meriden, CT 06450-1019 TELIX 152236417(wmlyman) (203)-237-7645
arubin@spies.UUCP (Andy Rubin) (05/13/88)
In article <113@3bee2.UUCP>, lyman@3bee2.UUCP (William S. Lyman Jr.) writes: > > H E L P !!! > > and throws it in junk. I have tried this on my 3b2 and 7300. > > William S. Lyman Jr. AT&T MAIL wmlyman or 3bee2!lyman Sounds like you're not in the news GRP when you do the polling. Be sure you "su news" before polling the remote site with uucico. -- Andy -- Spies in the Wire PUBLIC ACCESS UNIX | {allegra|ames|cmcl2|ihnp4|linus|uunet Mount Kisco, New York | |rutgers|gatech|mcnc|cbosgd|sdcsvax | |decvax}!philabs!spies!arubin (914) 666-3997 300/1200 8N1 | <arubin@spies.UUCP>
ccea3@rivm.UUCP (Adri Verhoef) (05/17/88)
In article <113@3bee2.UUCP> lyman@3bee2.UUCP (William S. Lyman Jr.) writes: > > H E L P !!! > > I am running the News software for Usenet and when it goes to create >a directory for the new group it is not what I defined it for in local- >ize.sh it is making them Owner root Grp root. Thenit can't write the articial > and throws it in junk. I have tried this on my 3b2 and 7300. > It is probably simple. I'm just screwing something up yes? > > William S. Lyman Jr. AT&T MAIL wmlyman or 3bee2!lyman Yes, I have seen this behaviour before on three of our machines, a 3b2 running sysV 2.0.4, a 3b2 running 2.0.5, and a microVAX II running V.2, I checked the modes of rnews/inews, and they were OK. I checked news log files, I checked uucp log files, no funny things. I tried to have the error repeat itself, but it won't show up again under "normal" circumstances. I haven't seen the error showing up on sysV.3 machines. My `trimlib'- script (calling `report_awk') always notifies me of these things on all my `news'-machines. Now I was having a look at the news-sources (funcs.c:mkdir(path, perm)), and there may be a problem, I think, when there has to be created a directory by calling execlp("mkdir", "mkdir", path, NULL): /* (the original source-code is indented by one tab) */ #ifndef MKDIRSUB /* If we haven't mkdir(2), we use this one, ** however, if you have sysV.3, you'ld rather use mkdir(2), ** so, #define MKDIRSUB in "defs.dist". */ /* * make a directory. Also make sure that the directory is owned * by the right userid */ mkdir(path, perm) char *path; int perm; { int pid, status; #ifdef USG /* We live on USG */ char parent[200]; char *p; struct stat sbuf; /* * Make parent directory writable, because we will * be creating a directory owned by the real user, * rather than by news. */ (void) strcpy(parent, path); if (p = rindex(parent, '/')) { *p = '\0'; if (stat(parent, &sbuf) == 0) (void) chmod(parent, 0777); else return -1; } else return -1; #endif /* vfork() gets turned into fork() */ if (pid=vfork()) { status = fwait(pid); #if defined(USG) && !defined(CHEAP) /* We are NOT el CHEAPo */ if (pid=vfork()) (void) fwait(pid); /* So if the fork fails, we will not chown(2)! ** I think here we could have a (or maybe THE(?)) problem. */ else { setgid(gid); setuid(uid); if (chown(path, duid, dgid) == 0) (void) chmod(path, perm&(~N_UMASK)); _exit(0); } #endif /* USG && !CHEAP */ } else { (void) setgid(dgid); if (setuid(duid) < 0) (void) umask(0); else (void) umask(perm&N_UMASK); (void) execlp("mkdir", "mkdir", path, (char *)NULL); perror(path); _exit(1); } #ifdef USG (void) chmod(parent, sbuf.st_mode); /* Restore mode of parent */ #endif return status; } #endif /* !BSD4_2 */ /* Shouldn't this be "!MKDIRSUB" ? */ We have this: the directory gets created, but the owner stays Uid root (+ Gid root), (when a directory is created, the owner will initially be root, right?) and isn't changed into "news" (or "uucp" (!?!?) - uuxqt is run by "uucp", right?). This is what possibly happens: The parent directory gets changed to mode 777, then the subdirectory is created by "uucp", and the owner should have been changed to "uucp" by the system call, and failing that (obviously), the owner of the directory could not be set to "news" by "uucp", because the owner was still "root". But how and why does this happen? A kernel error? System V.2 bug? Somebody? Remember: I tested this twice today, but the newly created directory gets its owner "news", so it acts quite good most of the time, I think. A few questions to lyman@3bee2.UUCP (William S. Lyman Jr.): - did all the other directories get created OK? - was this the first time? - what version of UNIX are you running? - are you at patchlevel 14 (B news 2.11)? A warning: when the "junk" directory doesn't exist, and the non-junk directory creation fails, and the junk-directory creation fails (which happened to me one time), then the article(s) will get lost. :-(or maybe)-: or even :-) .
cks@ziebmef.UUCP (Chris Siebenmann) (05/19/88)
In article <113@3bee2.UUCP> lyman@3bee2.UUCP (William S. Lyman Jr.) writes: > I am running the News software for Usenet and when it goes to create >a directory for the new group it is not what I defined it for in local- >ize.sh it is making them Owner root Grp root. Make sure inews is setuid news, setgid news. That's what I run here (on a 3B1/7300), and I'm having no trouble with it. It is definetly not (as someone has already suggested) that your system is polling people not under the news uid; my system works just fine with uucp jobs running under the uucpadm UID. Also make sure that your inews is creating new directories mode 777 and that /usr/spool/news is also mode 777 (see the comments in the news installation documentation for why this is necessary). -- "Oh BLESS you, sir! The ANGEL OF DEATH was after me just as SURE as you're standing there, yes he WAS!" Chris Siebenmann {uunet!mentor!lsuc,utgpu}!ncrcan!ziebmef!cks cks@ziebmef.UUCP or ...!utgpu!{radio,ontmoh,ncrcan!brambo}!cks
ccea3@rivm.UUCP (Adri Verhoef) (05/31/88)
In article <377@ziebmef.UUCP> cks@ziebmef.UUCP (Chris Siebenmann) writes: >In article <113@3bee2.UUCP> lyman@3bee2.UUCP (William S. Lyman Jr.) writes: >> I am running the News software for Usenet and when it goes to create >>a directory for the new group it is not what I defined it for in local- >>ize.sh it is making them Owner root Grp root. > > Make sure inews is setuid news, setgid news. That's what I run here >(on a 3B1/7300), and I'm having no trouble with it. It is definetly >not (as someone has already suggested) that your system is polling >people not under the news uid; my system works just fine with uucp >jobs running under the uucpadm UID. Also make sure that your inews is >creating new directories mode 777 and that /usr/spool/news is also >mode 777 (see the comments in the news installation documentation for >why this is necessary). Sorry. This is definitely NOT necessary. And rnews IS set[ug]id news. OK. Here I go again (since there was no response at my previous writing): Path: rivm!ccea3 >From: ccea3@rivm.UUCP (Adri Verhoef) Newsgroups: comp.sys.att Subject: Re: Dir Permissions Keywords: Usenet Trouble Message-ID: <825@rivm05.UUCP> Date: 16 May 88 18:19:31 GMT /* Two weeks ago now */ References: <113@3bee2.UUCP> Reply-To: ccea3@rivm05.UUCP (Adri Verhoef) Organization: RIVM, Bilthoven, The Netherlands Lines: 128 In article <113@3bee2.UUCP> lyman@3bee2.UUCP (William S. Lyman Jr.) writes: > > H E L P !!! > > I am running the News software for Usenet and when it goes to create >a directory for the new group it is not what I defined it for in local- >ize.sh it is making them Owner root Grp root. Thenit can't write the articial > and throws it in junk. I have tried this on my 3b2 and 7300. > It is probably simple. I'm just screwing something up yes? > > William S. Lyman Jr. AT&T MAIL wmlyman or 3bee2!lyman Yes, I have seen this behaviour before on three of our machines, a 3b2 running sysV 2.0.4, a 3b2 running 2.0.5, and a microVAX II running V.2, I checked the modes of rnews/inews, and they were OK. I checked news log files, I checked uucp log files, no funny things. I tried to have the error repeat itself, but it won't show up again under "normal" circumstances. I haven't seen the error showing up on sysV.3 machines. My `trimlib'- script (which calls `report_awk') always notifies me of these things on all my `news'-machines. Now I was having a look at the news-sources (funcs.c:mkdir(path, perm)), and there may be a problem, I think, when there has to be created a directory by calling execlp("mkdir", "mkdir", path, NULL): /* (the original source-code is indented by one tab) */ #ifndef MKDIRSUB /* If we haven't mkdir(2), we use this one, ** however, if you have sysV.3, you'ld rather use mkdir(2), ** so, #define MKDIRSUB in "defs.dist". */ /* * make a directory. Also make sure that the directory is owned * by the right userid */ mkdir(path, perm) char *path; int perm; { int pid, status; #ifdef USG /* We live on USG */ char parent[200]; char *p; struct stat sbuf; /* * Make parent directory writable, because we will * be creating a directory owned by the real user, * rather than by news. */ (void) strcpy(parent, path); if (p = rindex(parent, '/')) { *p = '\0'; if (stat(parent, &sbuf) == 0) (void) chmod(parent, 0777); else return -1; } else return -1; #endif /* vfork() gets turned into fork() */ if (pid=vfork()) { status = fwait(pid); #if defined(USG) && !defined(CHEAP) /* We are NOT el CHEAPo */ if (pid=vfork()) (void) fwait(pid); /* So if the fork fails, we will not chown(2)! ** I think here we could have a (or maybe THE(?)) problem. */ else { setgid(gid); setuid(uid); if (chown(path, duid, dgid) == 0) (void) chmod(path, perm&(~N_UMASK)); _exit(0); } #endif /* USG && !CHEAP */ } else { (void) setgid(dgid); if (setuid(duid) < 0) (void) umask(0); else (void) umask(perm&N_UMASK); (void) execlp("mkdir", "mkdir", path, (char *)NULL); perror(path); _exit(1); } #ifdef USG (void) chmod(parent, sbuf.st_mode); /* Restore mode of parent */ #endif return status; } #endif /* !BSD4_2 */ /* Shouldn't this be "!MKDIRSUB" ? */ We have this: the directory gets created, but the owner stays Uid root (+ Gid root), (when a directory is created, the owner will initially be root, right?) and isn't changed into "news" (or "uucp" (!?!?) - uuxqt is run by "uucp", right?). This is what possibly happens: The parent directory gets changed to mode 777, then the subdirectory is created by "uucp", and the owner should have been changed to "uucp" by the system call, and failing that (obviously), the owner of the directory could not be set to "news" by "uucp", because the owner was still "root". But how and why does this happen? A kernel error? System V.2 bug? Somebody? Remember: I tested this twice today, but the newly created directory gets its owner "news", so it acts quite good most of the time, I think. A few questions to lyman@3bee2.UUCP (William S. Lyman Jr.): - did all the other directories get created OK? - was this the first time? - what version of UNIX are you running? - are you at patchlevel 14 (B news 2.11)? A warning: when the "junk" directory doesn't exist, and the non-junk directory creation fails, and the junk-directory creation fails (which happened to me one time), then the article(s) will get lost. :-(or maybe)-: or even :-) .
pete@octopus.UUCP (Pete Holzmann) (05/31/88)
In article <883@rivm05.UUCP> ccea3@rivm05.UUCP (Adri Verhoef) writes: }>In article <113@3bee2.UUCP> lyman@3bee2.UUCP (William S. Lyman Jr.) writes: }>> I am running the News software for Usenet and when it goes to create }>>a directory for the new group it is not what I defined it for in local- }>>ize.sh it is making them Owner root Grp root. }And rnews IS set[ug]id news. }Yes, I have seen this behaviour before on three of our machines, a 3b2 }running sysV 2.0.4, a 3b2 running 2.0.5, and a microVAX II running V.2, }I checked the modes of rnews/inews, and they were OK. }I checked news log files, I checked uucp log files, no funny things. } }I tried to have the error repeat itself, but it won't show up again }under "normal" circumstances. } }I haven't seen the error showing up on sysV.3 machines. }But how and why does this happen? A kernel error? System V.2 bug? } Somebody? } }Remember: I tested this twice today, but the newly created directory gets }its owner "news", so it acts quite good most of the time, I think. }A few questions: }- did all the other directories get created OK? }- was this the first time? }- what version of UNIX are you running? }- are you at patchlevel 14 (B news 2.11)? Well, we've got the same problem here, running V.2 with some Berkeley utilities and line driver stuff added in (a Stride Micro). I've noticed a few things that may be helpful: - If the group gets created by default (an article comes in under a new group name; we accept the distribution already, so the group gets auto-created), then the owner/group/perms are just fine. - If the new group gets created by an administrative command from afar (as happens with most new groups), the permissions are ALWAYS wrong (root/root). - Don't know about locally created groups. I've never done it. - We are running patchlevel 14 Maybe this will help? Pete -- OOO __| ___ Peter Holzmann, Octopus Enterprises OOOOOOO___/ _______ USPS: 19611 La Mar Court, Cupertino, CA 95014 OOOOO \___/ UUCP: {hpda,pyramid}!octopus!pete ___| \_____ Phone: 408/996-7746