I started a reply on the python-mentoring maillist - and promised to come back here.

a) imho - the discussion about an "attacker" is only misleading for the general case. For active attacks - where an attacker has active acces to the system is not something that is the responsibility of "stdlib". On POSIX, one of the first things I would consider is adding the "STX" bit so that only root and the file owner can remove an existing "link" to an inode (a symbolic link is a "special" file whose contents is the PATH to yet another filesystem "name" regardless of it's type.) For reference, a hard-link "merely" increases the number of links to an inode - and so only works for non-directory objects within the same filesystem). Puf!

b) the "real", again imho, security issue is one of system integrity. Compare this "race" condition with a multi-user database (think of directories as the "index" to a data-record. A user that trusts the file-system index to refer to the correct file-system object (file, directory, other special file) - especially when there is no way for the user to verify the accuracy of the symbolic link. Any application, especially if it runs as "root" needs to be extremely cautious with "overwriting" existing "records". It is asif as database admin just changes where one database record references - as is, I cannot change the data it references - so I just change what it goes to - where I can change the data. -- As I think about it - an application that is dependent on symbolic links has an inherent weakness.

In short - I would be against this - if security is the primary argument for developing it. I would rather be notified that there is an existing symbolic link - where there should not be - and consider later action.

a) an application, running as root, can override any security measure I can come up with. The is the core "weakness" of UNIX/POSIX access control. When not running as root - there are mechanisms that can block the removal of any directory entry (the unlink() call).

b) so, if you want to consider adding a "user-friendly" force option, just as POSIX ln does (whether for hard or soft links) - then that is, imho - a different discussion. I would tend to be "against" making it too easy, because an application coded with "Force=true" would never get the feedback that something already exists. If the currect implementation returns the a "fatal" error - that needs to be fixed.

In short, I do not think it is the task of Python to rewrite the behavior of the system calls being used - and/because I fear lazy programmers (being there, done that!).

"ls -sf xxx yyy" and/or "ln -f xxx yyy" is a convenience. Using it as a default is "bad-practice" (imho) - and I fear programmers would use this new "feature" and move to "bad practice"

Michael