Date: Wed, 15 Dec 1999 01:28:28 -0800 (PST) From: "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net> To: dillon@apollo.backplane.com (Matthew Dillon) Cc: louie@TransSys.COM (Louis A. Mamakos), obrien@NUXI.com, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/usr.sbin/chown Makefile Message-ID: <199912150928.BAA21808@gndrsh.dnsmgr.net> In-Reply-To: <199912150451.UAA26014@apollo.backplane.com> from Matthew Dillon at "Dec 14, 1999 08:51:40 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> :That actually makes more since! It also narrows the race window between
> :mknod and chown/chmod, which technically could be a security issue. Haven't
> :seen any exploits written that sit and spin waiting for a new open device
> :node, but that doesn't mean one couldn't be written :-)
> :..
> :This does go against my grain of though that unix commands should do one
> :thing and one thing only, but but I could arguee with myself that creating
> :a device node includes doing so with correct owner ship and permissions,
> :just as install does when installing a file.
> :
> :
> :--
> :Rod Grimes - KD7CAX @ CN85sl - (RWG25) rgrimes@gndrsh.dnsmgr.net
>
> Yes. Think about how many places mknod is actually used - personally
> speaking, I don't think I've ever used the command directly. Only
> MAKEDEV really uses it on a regular basis. So mknod seems to be the
> perfect place to add the necessary MAKEDEV support.
Okay. I can make strong assertions that mknod(8) should have a mode
argument, as mknod(2) does. This falls from reasoning out that these
types of commands are interfaces to system calls. One can also note
that mkdir(1) takes -m mode, as mkdir(2) takes mode_t mode as an argument.
Furthermore mknod(1) arguable does a nasty:
mode = 0666;
and calls mknod with that value, thus opening a window of security
breach should it be used when multi-user unless root is running with
a reasonable umask. This window would be reduced to a kernel race
condition that would need to be checked, and from my walk through
the code does not exist.
That crosses the first bridge, -m mode should be added to mknod by reason
of syscall vs command interface. This also applies to mkfifo which has
no -m option, yet the system call does. Perhaps it is time to sweep the
tree looking for more of these...
It raises a further question in my mind, should mknod(2) take owner and
group arguments as well? mknod is a suser restricted system call, used
by very few programs, and even fewer if any outside the base OS.
There is a problem here though, the kernel imposes the umask and that
could get in the way unless an explicit umask 0 is done before the call
to mknod(2). Or the kernel could be modified to _stop_ using the umask,
though this would be a functional change going back as far as V6. I
think a umask (0); is a no worse than the current mode=666 :-).
Now, about adding -o owner and -g group to mknod, does anyone have any
major thoughts on this one? I can see that we would have a race between
mknod() and chown() but that is no worse than the race we have now at
the command shell level.
--
Rod Grimes - KD7CAX @ CN85sl - (RWG25) rgrimes@gndrsh.dnsmgr.net
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199912150928.BAA21808>