This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 181967 - Configuration rewrite breaks symlink
Configuration rewrite breaks symlink
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: netatalk (Show other bugs)
10
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jiri Skala
bzcl34nup
: Reopened, Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-02-17 19:38 EST by JW
Modified: 2014-11-09 17:30 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-12-18 00:51:29 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Alternative lrename() function which doesn't break destination symlinks (1.45 KB, text/plain)
2006-03-04 21:53 EST, JW
no flags Details

  None (edit)
Description JW 2006-02-17 19:38:38 EST
Description of problem:
If atalkd.conf is a symlink to something then atalkd destorys the symlink when
updating the configuration interface settings.

Version-Release number of selected component (if applicable):
netatalk-2.0.2-3

How reproducible:
always

Steps to Reproduce:
1.ln -s something atalkd.conf
2.run atalkd
3.
  
Actual results:
symlink destoryed and replaced by plain file

Expected results:
symlink preserved

Additional info:
The rename() in etc/atalkd/config.c should be changed to a copy().
Then somebody should write a copy() for libc to parallel the existing rename()
function.
Comment 1 Jason Vas Dias 2006-02-20 16:22:30 EST
There is currently no atomically secure way of copying a file, in the same 
way as rename(2), that would not leave atalkd open to attacks. rename(2) 
replaces the symlink target because if it followed the symlink, this would
create a security vulnerability.

There is an easy workaround for this problem: do not use symlinks for 
/etc/atalk/atalkd.conf - either use the system default /etc/atalk/atalkd.conf,
or add the '-f <config file location>' argument to the atalkd command in 
/etc/init.d/atalk, lines 27 and 38:
change the 
  daemon atalkd -f /etc/atalk/atalkd.conf
lines to
  daemon atalkd -f ${...my atalkd location...}/atalkd.conf

Sorry, but I don't think this problem warrants a respin of the FC-4 netatalk
package, and there is an easy workaround - closing as NOTABUG .
Comment 2 JW 2006-02-20 17:12:15 EST
> There is currently no atomically secure way of copying a file,
> in the same way as rename(2), that would not leave atalkd open to attacks.

Why would atomicity have anything to do with "attacks"?  It is plainly
obvious that nobody would run multiple instances of atalkd with the
same configuration file. So why is there any need for an atomic operation.
Nearly everything else that atalkd does is non-atomic!

I think your reason is a furphy.

> rename(2) replaces the symlink target because if it followed the symlink, this
would
> create a security vulnerability.

How would a symlink create a security vulnerability?  If symlinks were somehow a
security vulnerability they would have been invented.  To create the symlink you
need appropriate permission.  And the same rule applies to the target of the
symlink.

Most other applications can tolerate a symlink.  It would be nice if there was
consistent and safe handling of symlinks where they exist.

I think your reasoning is a seriously flawed.
Comment 3 Jason Vas Dias 2006-02-20 17:27:46 EST
atalkd uses rename(2) because an attacker could substitute a file of their choice
for atalkd.conf in the window created by other methods.

This problem does not warrant an FC-4 respin.

If you want to use a non-default location for atalkd.conf, use the 
atalkd '-f' option.
Comment 4 JW 2006-02-20 17:46:14 EST
(In reply to comment #3)
> atalkd uses rename(2) because an attacker could substitute a file of their choice
> for atalkd.conf in the window created by other methods.
>

An attacker could simply replace atalkd.conf with a file of their choice
regardless of whether it was a symlink or not!

What has happened over there in the USA?  Why is there so much paranoia about
attackers?  What on earth are they putting in the water supply over there?

> This problem does not warrant an FC-4 respin.
> 
> If you want to use a non-default location for atalkd.conf, use the 
> atalkd '-f' option.

I suggest you do "rm -fr /" so as to stop any attacker from compromising your
system.
Comment 5 Jason Vas Dias 2006-02-20 18:05:16 EST
Security is not the only reason for not fixing this bug .
The problem has a very easy workaround :
 - Edit /etc/init.d/atalk to use the atalkd '-f' option to specify your
   non-standard location for atalkd.conf .
Respinning netatalk in the stable FC-4 release is not warranted just to fix
this problem. 
RE: > Most other applications can tolerate a symlink. 
Most other applications do not attempt to re-write their own configuration file.
Comment 6 JW 2006-02-20 18:43:59 EST
(In reply to comment #5)
> The problem has a very easy workaround :
>  - Edit /etc/init.d/atalk to use the atalkd '-f' option to specify your
>    non-standard location for atalkd.conf .

I am sorry but it is not always possible when running a diskless DVD
installation which works on a variety of configurations.

Anyhow, I have already created a patch.

Are you going to breach the GPL licence for netatalk by not allowing me to
publish my patch?
Comment 7 JW 2006-02-20 18:47:27 EST
(In reply to comment #5)
> Most other applications do not attempt to re-write their own configuration file.

But many applications write files - not necessarily configuration files.  And
they generally manage to preserve symlinks.  So why should configuration files
be any different?

The badly behaved programs include cups, kudzu.
Comment 8 JW 2006-03-04 21:53:47 EST
Created attachment 125654 [details]
Alternative lrename() function which doesn't break destination symlinks

Here is an lrename() function that should be used instead of rename()

This is a lrename() function which differs from rename() in that it attempt to
follow a destination symbolic link.  It is as atomic as rename().  Using this
function instead of rename(P) will ensure that symbolic links are preserved if
possible, on the grounds that people create symbolic links intentionally and
they really want all file reading/writing to go to the symlink target and not
the symlink itself.

Symbolic links should be transparent as far as possible.
Comment 9 Christian Iseli 2007-01-19 19:53:30 EST
This report targets the FC3 or FC4 products, which have now been EOL'd.

Could you please check that it still applies to a current Fedora release, and
either update the target product or close it ?

Thanks.
Comment 10 JW 2007-01-19 20:05:39 EST
It is up to the person to whom this bug is assigned to ask for more information.
 Of Christian Iseli wants more information then he can make that determination
himself.
Comment 11 Matthew Miller 2007-04-10 15:38:57 EDT
Fedora Core 4 is now completely unmaintained. These bugs can't be fixed in that
version. If the issue still persists in current Fedora Core, please reopen.
Thank you, and sorry about this.
Comment 12 JW 2007-04-10 20:18:31 EDT
Applicable to Fedora Core 6. Sorry about this.
Comment 13 Martin Nagy 2008-03-06 02:42:41 EST
Hi, could you please send your patch upstream? I suggest that you send it to
netatalk-devel@lists.sourceforge.net
If it would get accepted into CVS HEAD I might backport it. Thanks.
Comment 14 Bug Zapper 2008-04-03 22:08:15 EDT
Fedora apologizes that these issues have not been resolved yet. We're
sorry it's taken so long for your bug to be properly triaged and acted
on. We appreciate the time you took to report this issue and want to
make sure no important bugs slip through the cracks.

If you're currently running a version of Fedora Core between 1 and 6,
please note that Fedora no longer maintains these releases. We strongly
encourage you to upgrade to a current Fedora release. In order to
refocus our efforts as a project we are flagging all of the open bugs
for releases which are no longer maintained and closing them.
http://fedoraproject.org/wiki/LifeCycle/EOL

If this bug is still open against Fedora Core 1 through 6, thirty days
from now, it will be closed 'WONTFIX'. If you can reporduce this bug in
the latest Fedora version, please change to the respective version. If
you are unable to do this, please add a comment to this bug requesting
the change.

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we are following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

And if you'd like to join the bug triage team to help make things
better, check out http://fedoraproject.org/wiki/BugZappers
Comment 15 Jiri Skala 2008-06-19 09:57:18 EDT
I'd like to ask reporter for answer to Comment #13. Thank you in advance.
Comment 16 JW 2008-06-19 18:05:57 EDT
Opened on 2006-02-17.  Currently 2008-06-19. Applicable to fc8.

Comment 17 Bug Zapper 2008-11-26 01:55:26 EST
This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '8'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 8's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 8 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 18 Bug Zapper 2009-11-18 03:05:43 EST
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 19 Bug Zapper 2009-12-18 00:51:29 EST
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.