Community hub
0 subscribers8 pages, 0 posts
Recent from talks
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
Welcome to the community hub built to collect knowledge and have discussions related to Ln (Unix).
Nothing was collected or created yet.
Ln (Unix)
View on Wikipediafrom Wikipedia
| ln | |
|---|---|
 Example usage of ln utility | |
| Original author | AT&T Bell Laboratories |
| Developers | Various open-source and commercial developers |
| Initial release | November 3, 1971 |
| Operating system | Unix, Unix-like, IBM i |
| Platform | Cross-platform |
| Type | Command |
| License | coreutils: GPLv3+ |
ln is a shell command for creating a link file to an existing file or directory.[1] By default, the command creates a hard link, but with the -s command line option, it creates a symbolic link.[2] Most systems disallow a hard link to a directory since such links could disrupt the structure of a file system and interfere with the operation of other utilities.[3] The command can create a symbolic link to non-existent file.[4]
The command appeared in Issue 2 of the X/Open Portability Guidelines.[5] The version in GNU Core Utilities was written by Mike Parker and David MacKenzie.[6] The command is available in Windows via UnxUtils[7] and has been ported to IBM i.[8]
Links
[edit]A link allows more than one path to refer to the same file.
A hard link is a directory entry that refers to a file's inode (an internal reference). A file can have multiple hard links – each referring to the same inode.[9] Creating a hard link does not copy the contents of the file; but merely causes another name to be associated with the same content. When a hard link is created for a file, a counter in its inode is incremented, and removing a hard link results in decrementing the counter. A file is not deleted (to allow reusing its storage space) until its reference count reaches zero.[1][10] A hard link can only refer to an object on the same file system.[11]
A symbolic link refers to another file by its path (a symbolic reference).[4] When encountered during pathname resolution, modify the pathname resolution to be taken to the location which the symbolic link contains. The content of a symbolic link is the target path, which can also be examined via the readlink command.[12] A symbolic link may specify a path that does not refer to an existing file. Resolving such a symbolic link will fail until a file is created at its specified path. Also, a symbolic link to an existing file will fail to resolve if the file is moved.[9]
Use
[edit]Per the Single Unix Specification, the ln command is specified in the Shell and Utilities (XCU) document.[13] POSIX includes a similar specification.[5]
If neither target file nor target directory are specified, links are created in the current working directory.
Options
[edit]The specification indicates command line options that must be supported:
-f(force) Clobbers an existing file if the output path specifies an existing file-LIf a source operand specifies a symbolic link, create a hard link to the link's target file-PIf a source operand specifies a symbolic link, create a hard link to the symbolic link file-sCreate symbolic links instead of hard links; causes-Land-Pto be silently ignored
If more than one of the mutually-exclusive options -L and -P is specified, the last option specified determines the resulting behavior.
If the -s option is not specified and neither a -L nor a -P option is specified, the implementation defines which of the -L and -P options is used by default.
Single file invocation
[edit]The command creates a new link to the path indicated by source; stored at the path indicated by target. The syntax is as follows:
ln [-fs] [-L|-P] source target
Multiple file invocation
[edit]The command creates a new link to each file specified by the source_# operands; stored in an existing directory indicated by target_dir.
ln [-fs] [-L|-P] source_1 source_2 ... target_dir
Examples
[edit]The following creates a hard link to file foo called bar.
ln foo bar
The following creates a symbolic link to file foo called bar.
ln -s foo bar
See also
[edit]References
[edit]- ^ a b Kernighan, Brian W.; Pike, Rob (1984). The Unix programming environment. Englewood Cliffs, N.J.: Prentice-Hall. p. 59. ISBN 013937681X.
- ^ "ln - The Open Group Base Specifications Issue 7". pubs.opengroup.org. The IEEE and The Open Group. Retrieved 7 August 2015.
- ^ "Why are hard links not allowed to directories in UNIX/Linux?". unix.stackexchange.com. Retrieved 7 August 2015.
- ^ a b "GNU Coreutils: ln invocation". gnu.org. Free Software Foundation, Inc. Retrieved 7 August 2015.
- ^ a b – Shell and Utilities Reference, The Single UNIX Specification, Version 5 from The Open Group
- ^ – Linux General Commands Manual from ManKier.com
- ^ "Native Win32 ports of some GNU utilities". unxutils.sourceforge.net.
- ^ IBM. "IBM System i Version 7.2 Programming Qshell" (PDF). IBM. Retrieved 2020-09-05.
- ^ a b Loosemore, Sandra; Stallman, Richard M.; McGrath, Roland; Oram, Andrew; Drepper, Ulrich. The GNU C Library Reference Manual (PDF). Free Software Foundation, Inc. p. 392. Retrieved 7 August 2015.
- ^ "Speaking UNIX: It is all about the inode". ibm.com. IBM developerWorks. Retrieved 7 August 2015.
- ^ Bovet, Daniel P.; Cesati, Marco (2005). Understanding the Linux Kernel (3rd ed.). Boston, MA: Safari Tech Books Online. p. 14. ISBN 0596005652.
- ^ "readlink(1) - Linux man page". linux.die.net. Retrieved 7 August 2015.
- ^ "The Single UNIX Specification, Version 4 - Overview". unix.org. unix.org. Retrieved 7 August 2015.
External links
[edit]
The Wikibook Guide to Unix has a page on the topic of: File System Utilities - ln
- – Linux User Commands Manual
- – FreeBSD General Commands Manual
- – NetBSD General Commands Manual
- – OpenBSD General Commands Manual
- – Darwin and macOS General Commands Manual
| File system | |
|---|---|
| Processes | |
| User environment | |
| Text processing | |
| Shell builtins | |
| Searching | |
| Documentation | |
| Software development | |
| Miscellaneous | |
| |
Ln (Unix)
View on Grokipediafrom Grokipedia
ln is a standard command-line utility in Unix-like operating systems for creating links between files, including both hard links, which directly reference the same file data on disk, and symbolic links, which point to another file or directory by path.[1]
By default, without the -s option, ln creates a hard link, which increments the link count of the target file and allows multiple directory entries to access the same inode, enabling efficient file sharing without duplication.[1] The -s option, introduced in POSIX.1-2004 and widely supported, instead produces a symbolic link—a special file containing the path to the target, which can span filesystems but become invalid if the target is moved, renamed, or deleted.[1] Common use cases include organizing filesystems, backing up data without redundancy, and managing software installations by linking executables or libraries.
The utility operates in two primary forms: linking a single source file to a target file or linking multiple source files into an existing target directory, with the -f option forcing overwrites of existing destinations to avoid errors.[1] Additional options like -L dereference symbolic links during hard link creation to target the actual file, while -P treats symbolic links as the links themselves, providing control over how links interact in complex directory structures.[1] As defined in IEEE Std 1003.1-2017 (POSIX.1-2017), ln exits with status 0 on success or greater than 0 on failure, such as permission denials or invalid paths, ensuring reliable scripting integration.[1]
Overview
Purpose and Functionality
Theln utility in Unix-like systems is a command-line tool designed to create links between files and directories, facilitating efficient file management without physical duplication of data.[2] Specifically, it supports the creation of hard links, which are additional directory entries pointing to the same underlying file data via a shared inode—a data structure that stores file metadata and data block pointers in file systems such as ext4 on Linux.[2][3] In contrast, symbolic links (also known as soft links) are special files that contain a path reference to the target file or directory, resolved at access time rather than directly accessing the inode.[2] This distinction allows hard links to provide direct, transparent access to the same content across multiple names, while symbolic links offer flexibility in pointing to relocated or remote targets.[3]
By enabling multiple references to the same file data, ln promotes resource efficiency in storage and access, as modifications to the linked content propagate across all hard links due to their shared inode, avoiding the need for redundant copies that would consume additional disk space.[3] Symbolic links, meanwhile, support scenarios where the target might be moved or deleted, potentially resulting in "dangling" links if the path becomes invalid, but they do not duplicate data.[2] These mechanisms integrate seamlessly with modern file systems like ext4, which uses inodes to manage hard links with reference counting to track usage, and APFS on macOS, which supports both link types for files while optimizing space through copy-on-write for certain operations.[4]
The ln command adheres to POSIX standards, ensuring portability across compliant Unix-like environments, including Linux, BSD, and macOS derivatives.[2] Originating as part of the early Unix system in the 1970s at Bell Labs, it has remained a core utility essential for system administration tasks, shell scripting, and strategies to minimize data redundancy in multi-user and networked environments.[5]
Historical Development
Theln command originated in AT&T Unix Version 7, released in 1979, where it was implemented to create hard links, allowing multiple directory entries to reference the same underlying file via its inode without duplicating data.[6] This functionality drew conceptual influence from the Multics operating system, which featured a hierarchical file structure with both hard links (termed "branches") and symbolic links, emphasizing shared access to file content across multiple names.[7][8]
Symbolic links, enabling cross-filesystem references and directory pointing, were introduced later in 4.1c BSD in 1982, extending the ln command with the -s option to support this feature and addressing limitations of hard links in distributed environments.[9][10] This addition marked a key divergence between BSD and System V Unix variants; while BSD rapidly adopted symbolic links for flexibility, AT&T's System V initially lacked them, relying solely on hard links until their integration in SVR4 around 1988.[11]
The ln command's evolution continued with its formalization in the POSIX.2-1992 standard, which mandated support for both hard and symbolic links via ln with the -s option, ensuring portability across Unix-like systems by defining behaviors like link creation and traversal.[12] Earlier revisions in POSIX.1-1990 introduced system calls such as lstat and readlink to safely handle symbolic links without following them, with further refinements in later standards.[13]
Adoption extended to new platforms, including Linux in 1991, where early distributions incorporated ln via GNU utilities like coreutils, preserving Unix compatibility. Similarly, macOS, derived from BSD Unix through NeXTSTEP, inherited the ln command's BSD-style implementation, supporting both link types natively.
In the 2020s, enhancements focused on security, with GNU coreutils 9.0 (released September 2021) adding the --relative option to ln for generating relative symbolic links, improving portability in containerized environments, and GNU Coreutils 9.9 (released November 2025) providing stability fixes and performance improvements.[14][15][16] Linux kernel updates addressed symlink race conditions—time-of-check-to-time-of-use vulnerabilities—through features like protected symlinks (enabled via fs.protected_symlinks=1 since kernel 2.6.19 but refined in later versions) and patches for specific CVEs, such as CVE-2022-3328 in snapd, to prevent privilege escalation via manipulated links.[17][18]
Syntax and Options
Basic Syntax
Theln command in Unix-like systems follows a standardized syntax for creating links between files or directories, as defined in the POSIX specification.[1] The general form of the command is ln [options] source target for linking a single source file or path to a specified target name, or ln [options] sources... directory for linking multiple source files into an existing target directory.[1] In both cases, the [options] placeholder allows for optional flags that modify behavior, though the core invocation relies on the positional arguments without them.
The source argument refers to an existing file or path that serves as the basis for the link, while the target specifies the new name or location for the link in the single-file form; if the target already exists, the command typically fails with an error unless overridden by specific options like -f.[1][19] For the multiple-sources form, the directory must already exist, and the command creates links within it using the basenames of the sources; otherwise, it results in an error such as the directory not found (e.g., ENOENT for non-existent paths).[1][19] Invalid paths in either argument, such as a non-existent source, trigger standard system errors like ENOENT to indicate the failure.[1]
Shell expansion applies to the arguments provided to ln, allowing wildcards and other shell features to resolve before the command processes them.[19] The default behavior regarding dereferencing symbolic links during link creation is implementation-defined if neither -L nor -P is specified; for example, in GNU coreutils, symbolic links are followed by default unless -P is used.[1][19] This provides control over whether hard or symbolic links are formed to the actual files or to the links themselves.
Common Options
Theln command supports several options that modify the behavior of link creation, allowing users to control aspects such as link type, overwriting, and verbosity. These options are standardized in part by POSIX and extended in implementations like GNU coreutils.[1][20]
The -s or --symbolic option creates symbolic links rather than hard links, enabling links to non-existent files (dangling links) or across different filesystems, though it fails on systems lacking symlink support.[20] This is a POSIX-specified option, which takes precedence over dereferencing behaviors if combined with other flags.[1]
The -f or --force option removes any existing destination files or links before creating the new link, preventing errors from conflicts without prompting.[20] Defined in POSIX, it ensures the link operation proceeds by overriding existing targets.[1]
The -n or --no-dereference option, available in GNU coreutils, treats a symbolic link to a directory as a regular file rather than dereferencing it, avoiding accidental overwrites of directory contents.[20] This security-focused flag, introduced in later versions around the 2010s, helps prevent unintended modifications when the target is a symlink.[20]
The -v or --verbose option enables verbose output, printing a message for each successful link creation, such as 'ln: creating symbolic link 'target' to 'source''.[20] This aids in monitoring operations, particularly in scripts or batch processing.
The -i or --interactive option prompts the user for confirmation before overwriting existing destination files, requiring an affirmative response to proceed.[20] While not part of the core POSIX specification, it is a common extension for safer interactive use.[1]
The --backup option, a GNU extension, creates backups of files that would otherwise be overwritten or removed, typically by appending a suffix like ~ to the original name.[20] This preserves data during link operations involving conflicts.[21]
Link Types
Hard Links
Hard links in Unix file systems represent multiple directory entries that associate different filenames with the same underlying file data through a shared inode, the data structure that stores file metadata such as permissions, timestamps, and the location of the file's content blocks.[22] Each hard link increments the link count field within the inode, which tracks the number of such directory entries referencing it; this count can be viewed using commands likels -l to display the number of links or stat to retrieve detailed inode information including the link count.[3] Unlike a single filename, which initially sets the link count to 1, additional hard links ensure that modifications to the file's content via any linked name affect all instances, as they all resolve to the identical inode and data.[22]
The ln command creates hard links by default when invoked without the -s option, establishing a new directory entry that points to the target file's inode on the same filesystem.[19] This operation requires the source and target to reside on the same mounted filesystem, as cross-filesystem hard links are not possible due to the inode's filesystem-specific nature; attempting otherwise results in an error.[22] Directory hard links are prohibited to prevent filesystem cycles and maintain tree structure integrity; this restriction applies even to superusers.[19] Regular files and other non-directory objects are the primary targets.[19]
Hard links are subject to filesystem-imposed limits on the maximum number of links per inode, such as 65,000 in the ext4 filesystem, beyond which creation fails with an appropriate error.[23] Deletion of a hard link merely removes one directory entry and decrements the inode's link count, leaving the file data intact as long as the count remains above zero; the actual file removal, including deallocation of its data blocks, occurs only when the link count reaches zero.[22] This reference-counting mechanism ensures data persistence until all references are eliminated.[3]
A significant advantage of hard links is their ability to maintain content integrity even if the original filename is renamed or moved within the same filesystem, since all links continue to reference the unchanged inode and data.[3] This property makes hard links particularly valuable for scenarios like creating space-efficient backups or versioning systems, where multiple access points to the same data avoid unnecessary duplication while preserving accessibility.[22] In contrast to symbolic links, which are path-based pointers that can span filesystems but may dangle if the target moves, hard links provide a more robust, direct binding to the file's essence.[3]
Symbolic Links
Symbolic links, also known as soft links, are special files in Unix-like operating systems that contain a pathname string pointing to another file or directory, functioning as indirect references to the target. When accessed, the operating system dereferences the symbolic link by following the stored path to the target, which enables support for cross-device linking and the creation of dangling links if the target does not exist. This pointer-based mechanism contrasts with hard links by allowing references to directories and locations outside the same filesystem.[24] Symbolic links are created using theln command with the -s option, specified as ln -s source target, where the source is the path to the target file or directory. If the target already exists as a symbolic link to a directory, ln follows it by default unless the -n option is used to avoid dereferencing and treat the link as a non-directory. Symlink cycles, where links form loops, are possible due to this indirection but are detected by the kernel through a limit on the depth of dereferences, returning an ELOOP error to prevent infinite recursion.[25][24]
Key properties of symbolic links include a file size equivalent to the length of the embedded pathname string (excluding the null terminator), which is displayed by commands like ls -l. Their mode bits are fixed at 0777 and cannot be altered via chmod, though the effective permissions upon access are determined by those of the target; ownership can be changed using lchown. Deletion of a symbolic link removes only the link itself, leaving the target unaffected and independent.[26][24]
Symbolic links were introduced in 4.2BSD to provide greater flexibility in file system navigation and organization compared to hard links. In contemporary Linux environments, they play a crucial role in package management systems, such as the /etc/alternatives mechanism, which employs symbolic links to dynamically switch between multiple implementations of essential commands like editors or Java runtimes.[27][28]
Usage Scenarios
Single File Operations
Theln command, when invoked as ln source_file target_file, creates a new directory entry at the destination path specified by target_file, linking it to the existing source_file.[1] By default, this produces a hard link, which references the same underlying inode and data blocks as the source, without copying the file contents.[1] The target path is resolved relative to the current working directory if relative, or absolutely if specified as such; the link is placed in the parent directory of target_file using its basename.[1]
Common scenarios for single file operations include creating hard links to executables for alternative naming within the same filesystem, such as linking /bin/ls to a local alias to simplify access without altering the PATH.[29] Another frequent use is simulating a rename operation without data movement: a hard link is created at the desired new path, allowing the original name to be removed afterward while preserving file integrity and avoiding storage duplication.[3]
Key implications of these operations involve path resolution and error handling; if target_file already exists, ln fails with an EEXIST error unless the -f option forces removal of the existing entry first.[1] Hard links inherently preserve the source's timestamps, permissions, and ownership, as they share the inode.[3] For symbolic links, the -s option must be specified, resulting in a distinct file containing the path to source_file rather than sharing the inode.[1]
Single file linking operations are atomic, executed via the link() or symlink() system calls, which ensures indivisibility and prevents partial states—making them ideal for scripting scenarios where temporary files or race conditions must be avoided.[22]
Multiple File Operations
Theln utility supports linking multiple source files or directories to entries within a single target directory by specifying the sources followed by the directory as the final operand, in the form ln [options] source1 source2 ... target_dir.[1] In this mode, each source is linked into the target directory using the basename of the source path, preserving the original filenames without recursion into subdirectories.[20] For instance, invoking ln file1 file2 /links/ would create /links/file1 and /links/file2 as links to the respective sources.[1]
The target directory must preexist and be writable by the invoking process; otherwise, the operation fails for all sources.[1] Sources may include a mix of regular files and directories, though hard links (the default) cannot typically be created to directories due to filesystem restrictions that prevent cycles in the directory hierarchy.[20] Symbolic links, enabled via the -s option, have no such limitations and can freely target directories.[1]
This multiple-source form operates non-interactively by default, refusing to overwrite existing destinations (and failing with an error unless the -f option is used), making it efficient for batch operations such as populating a directory with links to selected files from various locations.[20] It provides a lightweight alternative to copying for replicating access to file sets across the same filesystem, avoiding data duplication while maintaining reference integrity.[20] Although the POSIX standard does not mandate a trailing slash on the target directory operand, many implementations infer its directory nature from existence checks, ensuring compatibility without explicit notation.[1]
Examples and Best Practices
Basic Examples
To create a basic hard link between two files in the same directory, use the commandln source.txt target.txt, which establishes a new directory entry pointing to the same inode as the source file, effectively creating an additional name for the same underlying data.[19] For instance, executing ln document.txt doc_hard.txt results in doc_hard.txt sharing the identical file content and metadata with document.txt, allowing modifications through either name to affect both.[19]
For symbolic links, which provide a reference to the target's path rather than its data, specify the -s option: ln -s /path/to/source target_link. A practical example is ln -s /etc/passwd passwd_link, creating passwd_link as a pointer to the system password file; accessing passwd_link will resolve to /etc/passwd if it exists, but the link becomes dangling if the target is moved or deleted.[19]
To overwrite an existing link or file without prompting, include the -f (force) option: ln -f source.txt target.txt. This removes the existing target.txt and replaces it with a new link to source.txt, useful when reusing names in scripts or workflows.[19][30]
Hard links can be verified by examining inode numbers with ls -li, where matching inodes confirm shared data structures; for example, after ln document.txt doc_hard.txt, the output might show identical inode values like 123456 -rw-r--r-- 2 user user 1024 Nov 11 10:00 document.txt and 123456 -rw-r--r-- 2 user user 1024 Nov 11 10:00 doc_hard.txt, indicating the link count of 2 for the shared inode.[19]
Advanced Examples
Advanced examples of theln command demonstrate its integration with multiple options and scripting for more sophisticated file system management tasks, such as ensuring portability in build environments or automating bulk operations while handling conflicts gracefully.[20]
Relative symbolic links are particularly useful in software builds and portable projects, where paths need to remain valid across different directory structures without relying on absolute locations. For instance, to link a shared resource directory relative to the current build context, the command ln -s ../shared lib creates a symbolic link named lib pointing to the parent directory's shared folder, promoting flexibility in deployment scenarios like containerized applications or version control repositories.[20] This approach leverages the -s option for symbolic linking, which supports relative path resolution based on the link's target directory.[1]
When performing batch linking operations where destination files might already exist, the -b option (GNU coreutils extension) enables automatic backups to prevent data loss. Consider linking multiple sources to a target directory with potential overwrites: ln -b file1 file2 /dir will create the links while renaming any conflicting files in /dir by appending a tilde (~) suffix, such as file1~, using the default backup method.[20] This is especially valuable in maintenance scripts updating configuration links across systems, ensuring idempotency without manual intervention.[21]
The -n option (GNU coreutils extension; equivalent to -h in some systems like FreeBSD), or --no-dereference, prevents the command from treating symbolic links to directories as directories themselves, avoiding unintended recursion or traversal. For example, ln -n -s link_to_dir subdir treats link_to_dir (a symlink pointing to a directory) as a plain file, creating subdir as a non-recursive link without following the original path.[20] This behavior is crucial in hierarchical file systems or when scripting link management in environments with nested symlinks, such as in package managers or virtual file systems.[1]
In scripting contexts, ln integrates seamlessly with shell loops for automated linking of file sets, enhancing efficiency in DevOps workflows like backups or deployment pipelines. A common pattern in Bash is:
for f in *.txt; do
ln -s "$f" /backup/
done
for f in *.txt; do
ln -s "$f" /backup/
done
.txt files in the current directory to /backup/, preserving original names and enabling quick synchronization without copying data.[20] Such automation is widely adopted for maintaining consistent access points in distributed systems, where relative or absolute linking can be adjusted based on runtime conditions.[1]
Limitations and Considerations
Behavioral Differences
Hard links and symbolic links, both created using theln command, exhibit distinct behaviors in access, deletion, and interaction with the file system. When accessing a hard link, the system directly references the shared inode, providing identical content, permissions, and metadata as the original file, with no additional resolution step.[19] In contrast, symbolic links store a pathname to the target file; accessing them requires the kernel to resolve this path, which succeeds only if the target exists and is accessible, otherwise resulting in an error such as "No such file or directory."[20]
Deletion behaviors further highlight these differences. Removing a hard link decrements the inode's reference count; the underlying file data and any remaining links persist until the count reaches zero, at which point the space is freed.[19] For symbolic links, deletion removes only the link file itself, leaving the target unaffected regardless of other references to it.[20]
File system interactions impose specific constraints on hard links, which must reside on the same device (filesystem); attempts to create them across mount points fail with an "Invalid cross-device link" error.[19] Symbolic links, however, can reference targets on different filesystems or even non-existent paths, enabling cross-mount operations but introducing indirection that incurs a slight performance overhead during resolution.[20]
The link type can be programmatically identified using the stat(2) system call, where symbolic links are distinguished by the S_IFLNK bit set in the st_mode field of the file status structure.[31]
Common Pitfalls and Security
One common pitfall when using theln command involves symlink races, particularly time-of-check-to-time-of-use (TOCTTOU) vulnerabilities, where an attacker exploits the window between checking a file's existence and linking to it, potentially redirecting the link to a malicious target.[32] These races are prevalent in Unix file system operations involving the link system call underlying ln, such as pairs like <stat, link> or <unlink, link>.[32] The -n (or --no-dereference) option mitigates some instances by treating a symbolic link to a directory as a regular file, preventing ln from dereferencing it and creating links inside what appears to be a directory, thus avoiding unintended overwrites or races in target resolution.[20]
Another pitfall is the inability to create hard links to directories, enforced by Unix-like systems to maintain the filesystem's directed acyclic graph structure and prevent cycles or dangling references that could corrupt the hierarchy.[3] Attempting ln on a directory typically results in an error like "hard link not allowed for directory," as this restriction avoids complex garbage collection and ensures filesystem integrity.[3] Broken symbolic links, created when the target is deleted or moved, represent additional pitfalls by consuming filesystem inodes and minimal disk space without providing utility, potentially cluttering directories and complicating maintenance.[33]
Security risks with ln include privilege escalation through hard links to setuid binaries, where an attacker creates a hard link in a user-controlled directory to a setuid executable, potentially bypassing access controls or "pinning" the file against removal during updates, allowing malicious execution with elevated privileges.[34] Using ln in untrusted directories, such as /tmp, heightens these risks due to symlink races that enable attackers to substitute targets, as seen in historical vulnerabilities like symlink attacks on shared library loaders in older glibc versions.[35] To counter symlink-based attacks, modern kernels provide mitigations like the O_NOFOLLOW flag in open(2), introduced in Linux kernel 2.1.126 in October 1998, which causes operations to fail if the final path component is a symbolic link.[36]
Best practices for safe ln usage include employing absolute paths when creating symbolic links in scripts, as relative paths can break if the working directory changes, leading to dangling links.[37] Verification of links can be performed using readlink to resolve and inspect targets, ensuring they point to intended files before further operations.[38] In containerized environments, modern Linux kernels (5.x and later) enforce restrictions via defaults like fs.protected_symlinks=1 (since kernel 3.6, standard in 5.x), limiting non-root users from following symlinks in world-writable directories to prevent container escapes or races during link creation.