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.
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 .
> 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.
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.
(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.
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.
(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?
(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.
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.
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.
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.
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.
Applicable to Fedora Core 6. Sorry about this.
Hi, could you please send your patch upstream? I suggest that you send it to netatalk-devel.net If it would get accepted into CVS HEAD I might backport it. Thanks.
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
I'd like to ask reporter for answer to Comment #13. Thank you in advance.
Opened on 2006-02-17. Currently 2008-06-19. Applicable to fc8.
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
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
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.