Bug 219143 - Why does avahi export an sftp service for all machines?
Summary: Why does avahi export an sftp service for all machines?
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: avahi   
(Show other bugs)
Version: 5.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: beta
: ---
Assignee: Lennart Poettering
QA Contact:
URL:
Whiteboard:
Keywords: Reopened
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-12-11 14:48 UTC by Alexander Larsson
Modified: 2018-10-27 14:28 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-01-13 12:24:41 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Add an attachment (proposed patch, testcase, etc.)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2010:0034 normal SHIPPED_LIVE avahi bug fix update 2010-01-13 12:24:30 UTC

Description Alexander Larsson 2006-12-11 14:48:27 UTC 
Why does avahi (via /etc/avahi/services/sftp-ssh.service) export an sftp service
on *all* machines by default.

This means that browsing the network for shares in e.g. nautilus will display
all the machines on the local network. In almost all cases this is not what you
want.
Comment 1 Lennart Poettering 2007-06-25 22:52:04 UTC 
Hmm, Why isn't this behaviour what you want? I think it makes a lot of sense to
be able to browse for all machines on the local LAN which you can access via sftp.
Comment 2 Alexander Larsson 2007-06-26 08:55:34 UTC 
Say you have an office with 100 desktop machines, and a few servers, some that
have often uses sftp shares. Now, the desktop machines run sshd to allow remote
maintainance (if e.g. someone calls helpdesk). However, exporting all these as
sftp shares makes lan browsing for sftp shares practically useless. Its
impossible to find the important/interesting shares. 

I *specifically* asked the mDNS people for a separate _sftp type (in addition to
the _ssh one) in order to not run into situations like this. (And it was added.)
Comment 3 Lennart Poettering 2007-07-24 22:08:31 UTC 
I guess you convinced me.

Any objections if I install ssh.sftp by default, then?
Comment 4 Lennart Poettering 2007-07-24 22:10:48 UTC 
oops!

That should read: "Any objections if I install ssh.service" by default, then?"

I also forgot to mention that I am going to remove ssh-sftp.service from the
next package version.
Comment 5 Alexander Larsson 2007-07-26 09:25:48 UTC 
ssh.service seems better suited for a default. Its not showing up much in
ordinary peoples UIs, and its mainly what ssh installs on desktops will be used for.
Comment 6 Lennart Poettering 2008-03-27 18:29:14 UTC 
This has been fixed a while back now.
Comment 7 ritz 2009-01-31 10:46:22 UTC 
This bug was marked against RHEL5, and not fedora(rawhide) , and thus re-opening it.

-- ritz
Comment 13 Lennart Poettering 2009-11-14 02:09:58 UTC 
I'd like to commit a fix for this. But cannot, because of this:

*** Commit denied
*** Current RHEL-5 checkin policy requires:
    (rhel-5.5.0 == + or (rhel-5.5.0 == ? and pm_ack == +))

Not sure what's missing here...
Comment 17 errata-xmlrpc 2010-01-13 12:24:41 UTC 
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2010-0034.html
Note You need to log in before you can comment on or make changes to this bug.