LCHOWN(3POSIX)

πŸ’… PROLOG πŸ’…

Okay bestie, real talk before we even start: this manual page is part of the POSIX Programmer's Manual. The Linux implementation of this interface may differ β€” so if you're on Linux, go consult the corresponding Linux manual page for the details of Linux behavior. Or, plot twist, the interface might not be implemented on Linux at all. πŸ™ˆ So like, vibe check your platform first, fr fr.


✨ NAME ✨

lchown β€” change the owner and group of a symbolic link πŸ¦‹


πŸŽ€ SYNOPSIS πŸŽ€

#include <unistd.h>

int lchown(const char *path, uid_t owner, gid_t group);

πŸ‘‘ DESCRIPTION πŸ‘‘

So lchown() is literally chown()'s twin sister, same energy, except for one very specific case: when the named file is a symbolic link. πŸͺž

In that case? lchown() shall change the ownership of the symbolic link file itself. Meanwhile chown() changes the ownership of the file or directory that the symbolic link refers to. It's giving "who are we even talking about" β€” the link, or the thing the link points at? lchown() says: the link. Periodt.


πŸ’– RETURN VALUE πŸ’–

Slay incoming: upon successful completion, lchown() shall return 0. πŸŽ‰

Otherwise it shall return -1 and set errno to indicate an error. Not the vibe. 😭


πŸ”₯ ERRORS πŸ”₯

The lchown() function shall fail if: πŸ’€

  • EACCES β€” Search permission is denied on a component of the path prefix of path.
  • EINVAL β€” The owner or group ID is not a value supported by the implementation.
  • ELOOP β€” A loop exists in symbolic links encountered during resolution of the path argument.
  • ENAMETOOLONG β€” The length of a component of a pathname is longer than {NAME_MAX}.
  • ENOENT β€” A component of path does not name an existing file, or path is an empty string.
  • ENOTDIR β€” A component of the path prefix names an existing file that is neither a directory nor a symbolic link to a directory, or the path argument contains at least one non-<slash> character and ends with one or more trailing <slash> characters and the last pathname component names an existing file that is neither a directory nor a symbolic link to a directory.
  • EPERM β€” The effective user ID does not match the owner of the file and the process does not have appropriate privileges.
  • EROFS β€” The file resides on a read-only file system.

The lchown() function may fail if: πŸ™ˆ

  • EIO β€” An I/O error occurred while reading or writing to the file system.
  • EINTR β€” A signal was caught during execution of the function.
  • ELOOP β€” More than {SYMLOOP_MAX} symbolic links were encountered during resolution of the path argument.
  • ENAMETOOLONG β€” The length of a pathname exceeds {PATH_MAX}, or pathname resolution of a symbolic link produced an intermediate result with a length that exceeds {PATH_MAX}.
The following sections are informative. (Read: optional lore, but honestly still cute.) 🫢

🌸 EXAMPLES 🌸

Changing the Current Owner of a File πŸ“

Bestie, here's how you change the ownership of the symbolic link named /modules/pass1 to the user ID associated with jones and the group ID associated with cnd. Iconic.

The numeric value for the user ID is obtained by using the getpwnam() function. The numeric value for the group ID is obtained by using the getgrnam() function. Teamwork, honestly. ✨

#include <sys/types.h>
#include <unistd.h>
#include <pwd.h>
#include <grp.h>

struct passwd *pwd;
struct group  *grp;
char          *path = "/modules/pass1";
...
pwd = getpwnam("jones");
grp = getgrnam("cnd");
lchown(path, pwd->pw_uid, grp->gr_gid);

🧚 APPLICATION USAGE 🧚

Lowkey important: on implementations which support symbolic links as directory entries rather than files, lchown() may fail. So like... no cap, that's a thing. 🌈


πŸ’œ RATIONALE πŸ’œ

None. Literally nothing. The silence is deafening. 😭


⭐ FUTURE DIRECTIONS ⭐

None. Also nothing. Stable queen behavior, honestly. πŸ‘‘


🌈 SEE ALSO 🌈

  • chown()
  • symlink()

The Base Definitions volume of POSIX.1‐2017, <unistd.h> πŸ¦‹


Portions of this text are reprinted and reproduced in electronic form from IEEE Std 1003.1-2017, Standard for Information Technology -- Portable Operating System Interface (POSIX), The Open Group Base Specifications Issue 7, 2018 Edition, Copyright (C) 2018 by the Institute of Electrical and Electronics Engineers, Inc and The Open Group. In the event of any discrepancy between this version and the original IEEE and The Open Group Standard, the original IEEE and The Open Group Standard is the referee document. The original Standard can be obtained online at http://www.opengroup.org/unix/online.html .

Any typographical or formatting errors that appear in this page are most likely to have been introduced during the conversion of the source files to man page format. To report such errors, see https://www.kernel.org/doc/man-pages/reporting_bugs.html .


Okay that's the whole page, you ate it up πŸ’… β€” this masterpiece comes courtesy of IEEE/The Open Group, 2017, and the manual page is LCHOWN(3POSIX). Byeee, go change some symlink ownership, bestie 🫢✨