Bug 1608176
| Summary: | nut cannot broadcast wall messages | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Fabrice Bellet <fabrice> |
| Component: | util-linux | Assignee: | Karel Zak <kzak> |
| Status: | CLOSED UPSTREAM | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 28 | CC: | jonathan, kzak, mhlavink, orion |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2019-02-14 09:47:55 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Fabrice Bellet
2018-07-25 06:19:29 UTC
It seems this is not related to upsmon being in the tty group. from strace: 16187 ioctl(1, TCGETS, 0x7ffeb6d9bd60) = -1 ENOTTY (Inappropriate ioctl for device) After some investigations: the wall pipe()ed command doesn't have a tty, and this is the cause of the ioctl error. But this error seems harmless and doesn't prevent the wall message to be broadcasted *if* the nut user is added to the tty group. So, the old sysvinit-tools package provided wall with the setgid bit set and the group set to tty to make this work. RHEL7 still has this: # ls -l /usr/bin/wall -r-xr-sr-x. 1 root tty 15344 May 2 2014 /usr/bin/wall* This went away in Fedora way back in 2013 when sysvinit-tools went away and util-linux started providing wall (see bug #987063). My question here is - was dropping the permissions from wall intentional or accidental? I agree that the warn("cannot get tty name") on failed ttyname() is overkill. It seems like absolutely useless information. I'll prepare upstream patch for this issue. Thanks for your report.
The setgid bit is another issue. We use 'tty' group for write(1), this command is usable to copy text between terminals. The command wall(1) is different, the goal is to write to *all* users. I have doubts it makes sense to provide this functionality to all users by g+s permissions. IMHO it makes sense for superuser only. I guess the current Fedora default is a good compromise. (But if you believe that we really need another setgrp bit that it would be better to move this discussion to fedora devel list.)
Note that with setgrp bit non-root user can only write to users who has allowed the messages by mesg(1). Only superuser (independently on 'tty' group) can write to all users...
I have removed the warning from upstream code. Thanks for your report. |