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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
