How to lock current->signal->tty

[Alan Cox <alan@lxorguk.ukuu.org.uk>]

The biggest crawly horror I've found so far in auditing the tty locking
is current->signal->tty. The tty layer currently and explicitly protects
this using tty_mutex. The core kernel likewise knows about this.

Unfortunately:
	SELinux doesn't do any locking at all
	Dquot passes the tty to tty_write_message without locking
	audit_log_exit doesn't do any locking at all
	acct.c thinks tasklist_lock protects it (wrong)
	drivers/char/sx misuses it unlocked in debug info
	fs/proc/array thinks tasklist_lock will save it (also wrong)
	fs3270 does fascinating things with it which don't look safe
	ebtables remote debugging (#if 0 thankfully) does no locking
		and just for fun calls the tty driver directly with no
		driver locking either.
	voyager_thread sets up a thread and then touches ->tty unlocked
		(and it seems daemonize already fixed it)
	Sparc solaris_procids sets it to NULL without locking
	arch/ia64/kernel/unanligned seems to write to it without locking
	arch/um/kernel/exec.c appears to believe task_lock is used

The semantics are actually as follows

signal->tty must not be changed without holding tty_mutex
signal->tty must not be used unless tty_mutex is held from before
reading it to completing using it
Simple if(signal->tty == NULL) type checks are ok

I'm looking longer term at tty ref counting and the like but for now and
current distributions it might be an idea to fix the existing problems.

Alan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/