Dir Permissions

[Adri Verhoef]

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 (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 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 :-) .