Dear Maintainer,

I read that mesg and write were removed recently because "people use
more secure methods of chatting nowadays." I am guessing this is
related to the recent security problem where Debian defaulted to 'mesg
n' and 'write' was not filtering Esc. Simply removing the programs may
seem like a fix, but unfortunately it is not so easy.

These are POSIX.2 shell tools which work universally and it would be a
shame if Debian were to be the incompatible UNIX.

Thanks,

Control: tags -1 = wontfix

Removing them is from my POV the right way to go. I somewhat expect
other mainline distros to do the same, sooner or later.

POSIX could/should change, I guess.

Chris

Thanks.

I apologize but I couldn't find where on the mailing list this was discussed so I need a little more info to proceed.

* I suspect this is unlikely, but is the "WONTFIX" just for until-linux, so it would be possible for Debian to ship these tools in a different package?

* Or, is the thinking that none of the Debian volunteers is willing to keep such crufty code audited and as such the programs are essentially orphaned?

* Is there some known or suspected attack vector other than through sending Esc? If so, it would be good for admins to know to be able to weigh the risks of manually installing the programs from source.

* What is Debian's suggestion now for communicating with users who are ssh'ed into a system?

Thank you for your time,

* Ben Wong <ben@wongs.net> [241125 06:47]:

As there was security context, the discussion was not on a public
mailing list, unfortunately.

The discussion on oss-security back then yielded that there is no
safe way of writing to another user's terminal.

Personally, I would talk to them, or send them a text.

Chris

I am of the belief this change is in violation of the Debian Policy
Manual version 2.5:

    Important programs, including those which one would expect to find
    on any Unix-like system. If the expectation is that an experienced
    Unix person who found it missing would say “What on earth is going
    on, where is foo?”, it must be an important package. [6] Other
    packages without which the system will not run well or be usable
    must also have priority important. This does not include Emacs, the
    X Window System, TeX or any other large applications. The important
    packages are just a bare minimum of commonly-expected and necessary
    tools.

    ...

    [6] This is an important criterion because we are trying to
    produce, amongst other things, a free Unix.

`write` and `msg` are both parts of POSIX as explained earlier
(https://pubs.opengroup.org/onlinepubs/9699919799.orig/,
https://pubs.opengroup.org/onlinepubs/9699919799.orig/). I, as an
experienced user and developer, attempted to use `write` to test it
before putting it in a privileged script, found it didn't exist,
discovered util-linux didn't have it anymore on my Trixie system, and
went "What on earth is going on, where is write?" To make matters more
confusing, the `wall` manpage still mentions `write` and `mesg`,
leading a user to believe that the utilities are supposed to be there.

util-linux's priority is "required", not just "important". It is
reasonable for users to assume that long-standing UNIX API components
will not simply vanish with no explanation other than "most people
probably use something else nowadays". Nowadays we have "better"
alternatives to a lot of core UNIX utilities, like `ls`, `cd`, etc. Are
we going to remove those in favor of "better" alternatives too? I would
surely hope not.

The fact that these utilities present a security risk if they are
allowed to be run by any arbitrary user is not a reason to remove them
entirely. They are still very useful for allowing privileged
scripts and applications to send notifications to individual users
without having to alert the entire workstation (or all of the users in
the target user's group) about whatever notification is being sent.
Removing SGID from them (as appears to have been done initially) was
the right thing to do, and I am perfectly happy with the removal of
the SGID bit from these executables remaining into perpetuity if there
really is no safe way to write to other user's terminals. But removing
the utilities entirely breaks one of the core goals of Debian stated by
the policy. Just because individual unprivileged users no longer have
good reasons to use these utilities doesn't mean the utilities
themselves are obsolete.

If bringing back `write` in util-linux is out of the question,
hopefully it can be placed in a new package with priority "important".

Control: severity -1 wishlist

write and mesg were removed due to security reasons. This part of
POSIX is inherently insecure and unfixable.

We're not gonna turn them back on.

Chris

On Fri, 29 Aug 2025 23:03:37 +0200 Chris Hofstaedtler <zeha@debian.org> wrote:

Chris,

The inherently insecure, unfixable security issues were remediated by
disabling the SGID bit on the executables. The executables themselves
are not capable of presenting any security risk to systems they are
installed on in this state beyond the risks any application written in
C presents. If `mount` were to have the SUID bit enabled, it too would
have unfixable security issues, so systems simply don't ship `mount`
SUID. There's no reason I can see to not do the same here.

The fact remains that there are use cases for these parts of POSIX that
do not require opening security holes. POSIX does not mandate that
these utilities be usable by arbitrary users, it does mandate that the
utilities exist, at least to my awareness. Debian policy mandates that
packages that provide standard utilities have priority "important" or
higher, which implies that packages with priority "important" or higher
should not have standard utilities removed unless all other options are
exhausted.

Unless there is an issue beyond the security issues that were plugged
by removing the SGID bit to justify the removal, this is still a
violation of Debian Policy by my reading and must be resolved (unless
my reading is wrong or the policy changes). If there are further
security issues, these need to be brought up or at least their existence
mentioned.

The severity of a bug is under discretion of the package maintainer,
unless being overridden by a delegate. AFAICT you are neither, so
please stop changing the bug severity.

They are not. Running 'mesg y' reopens the security hole ('write'
being only one of the tools that could be used). For trixie I tried
to have the defaults always be the equivalent of 'mesg n', or
better.

I consider write, mesg to be legacy interfaces. On a typical
install, they are purely dead weight.

I forgot if write even -works- on a default install, ISTR the answer
is 'no' (even after 'mesg y'). IIRC wall is also challenged on the
default install, but I opted to keep it for the sake of non-default
installs (sysvinit, etc).

I truly believe we are better off without these tools. I doubt
policy confines us to be a POSIX-compliant distro, and I would also
expect us to not be at any time. Bringing these tools back brings us
- from my PoV - nothing.

I also think your comment comparing these tools with other tools
to be an incorrect comparison. write/mesg/wall had a very small
usecase; ls is used by a lot more people. If ls would be mostly
useless on a default/typical install, it could also go away.

Chris

[..]

I'll also note, that, if you don't have write SGID, you don't need
write at all. Just use whatever tool you want to write to the tty.

Chris

On Sun, 31 Aug 2025 21:49:12 +0200 Chris Hofstaedtler <zeha@debian.org> wrote:

Sorry about that, I will stop. I was trying to make sure what I thought
was a policy violation would be solved or at least discussed, without
causing drama. I wasn't trying to be annoying, thank you for letting me
know this wasn't appropriate.

Originally I wrote quite a long reply to this, but then decided to try
and test functionality first. Unless the user runs `mesg y` *and*
/dev/ttyX is owned by group 'tty' *and* /usr/bin/write is SGID 'tty',
it doesn't work.

That's... not what I expected to be the case, it's not what the
manpage insinuated, and looking at the existing behavior, all I can say
is "that is ridiculous". Like seriously, why won't `write` just write if
it has write access, why does it *have* to have a group match? Why does
`mesg` make /dev/ttyX both group-writable and world-writable?
Furthermore, even running `sudo write`, `write` doesn't write to all
logged-in TTYs, it just chooses one and uses that specific one. That
makes it entirely unusable for what I wanted to use it for.

Sigh. I guess this is a good lesson for me to always test utilities
thoroughly rather than just blindly believing the manpage tells me all
I need to know. With how I understood `mesg` and `write` worked, I
couldn't see how the removal made sense, but now I can't see how these
tools ever were deemed fit for production use in the first place.

Sorry for the trouble, and thank you for your patience with me.