Dir Permissions

[Adri Verhoef]

In article <377 at ziebmef.UUCP> cks at ziebmef.UUCP (Chris Siebenmann) writes:
>In article <113 at 3bee2.UUCP> lyman at 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 at rivm.UUCP (Adri Verhoef)
Newsgroups: comp.sys.att
Subject: Re: Dir Permissions
Keywords: Usenet Trouble
Message-ID: <825 at rivm05.UUCP>
Date: 16 May 88 18:19:31 GMT	/* Two weeks ago now */
References: <113 at 3bee2.UUCP>
Reply-To: ccea3 at rivm05.UUCP (Adri Verhoef)
Organization: RIVM, Bilthoven, The Netherlands
Lines: 128

In article <113 at 3bee2.UUCP> lyman at 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 at 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 :-) .