|
|
Subscribe / Log in / New account

Review: The Linux Programming Interface

By Jake Edge
January 19, 2011

Michael Kerrisk's (relatively) new book, The Linux Programming Interface (TLPI), is targeted at Linux system programmers, but it is not just those folks who will find it useful. While it is a hefty tome ("thick enough to stun an ox" as Laurie Anderson might say), it is eminently readable, both by browsing through it or by biting the bullet and reading it straight through. The coverage of the Linux system call interface is encyclopedic, but the writing style is very approachable. It is, in short, an excellent reference that will likely find its way onto the bookshelves of user-space developers and kernel hackers—including some who aren't necessarily primarily focused on Linux.

[TLPI cover]

Kerrisk has been the maintainer of the Linux man pages since 2004, which gives him a good perspective on the Linux API. As he says in the preface, it is quite likely that you have already read some of his work in sections 2, 3, 4, 5, and 7 of those pages. But the book is not a collection of man pages though it covers much of the same ground. The style and organization is much less dry, and more explanatory, than a typical man entry.

The book is some 1500 pages in length, which makes it a rather daunting prospect to review. Once I started reading it, though, it was quite approachable. Kerrisk's clear descriptions of various system calls and other parts of the Linux API made it easy to keep reading. I set out to pick and choose certain chapters to read, and just skim the others, but found myself reading quite a bit more than that—which might partially explain the lateness of this review.

The book is organized into 64 chapters of around 20 pages each, which makes for nice bite-sized chunks that allow for reading the book around other tasks. While the focus is on Linux, Kerrisk doesn't neglect other Unix varieties and notes where they differ from Linux. He also pays careful attention to the various standards that specify Unix behavior—like POSIX and the Single Unix Specification (SUS)—pointing out where Linux does and does not follow those standards.

TLPI was written for kernel version 2.6.35 and glibc 2.12. In the text, though, Kerrisk is careful to indicate which kernel version introduced a new feature, so that those working with older kernels will know which they can use. While it is primarily looking at the 2.6 series, 2.4 is not neglected, and the text notes features that were introduced at various points in the 2.4 kernel history.

The book starts with a bit of history, going all the way back to Ken Thompson and Dennis Ritchie and then moving forward to the present, looking at the various branches of the Unix tree. It then moves into a description of what an operating system is, the role that the kernel plays, and some of the overarching concepts that make up Unix (and Linux). While this information may be unnecessary for most Linux hackers, it will come in handy for those coming to Linux from other operating systems. The ideas that "everything is a file" and that files are just streams of bytes are described in ways that will quickly get a system programmer up to speed on the "Unix way".

After that introductory material, Kerrisk launches into the chapters that cover aspects of the system call interface. This makes up the vast majority of the book and each of these chapters is fairly self-contained. They build on the earlier chapters, but the text is replete with references to other sections. In the preface, Kerrisk says that he attempted to minimize forward references, but that clearly was a difficult task as there are often as many forward as backward references in a chapter.

Navigating within the book is easy to do because there are frequent numbered section and subsection headings, along with the chapter number on each page. Other technical books could benefit from that style. There is also an almost too detailed index that runs to more than 50 pages.

Each chapter comes with sample code that is easy to read and understand. Importantly, the examples also do a good job of demonstrating the topic at hand and some of them could be adapted into useful utilities. The code is available from the TLPI web site and is free software released under the Affero GPLv3. Each chapter also has a handful of exercises for the reader, some of which have answers in one of the appendices.

So, what does the book cover? It would be easy to say "all of it", but that would be something of a cop-out, and a bit inaccurate as well. There are multiple chapters on files, file I/O, filesystems, and file attributes, extended attributes, and access control lists (ACLs). There is a chapter covering directories and links, as well as one that looks at the inotify file event notification call.

There are multiple chapters on processes, threads, signals, as well as chapters covering process groups and sessions, and process priorities and scheduling. Of particular interest to me were a chapter on writing secure privileged programs and one on Linux capabilities. There are two chapters on shared libraries, the first of which is more about the ideas underlying libraries and shared libraries along with how to build them, rather than the dlopen() system call (and friends), which is covered in the second.

There are, perhaps, too many chapters covering interprocess communication (IPC), with separate chapters devoted to each System V IPC mechanism (shared memory, message queues, and semaphores). There is also a chapter for each of the POSIX variants of those three IPC types. Both POSIX and System V IPC get their own introductory chapter in addition to the chapters focusing on the details of each type. Sandwiched between the System V and POSIX IPC mechanisms are two chapters on memory mapping and virtual memory operations that might have been better placed elsewhere in the book. There is also a chapter devoted to an introduction to IPC and one that looks at the more traditional Unix pipes and FIFOs. In all, there are twelve chapters on IPC before we even get to the sockets API.

After IPC, comes a chapter on file locking followed by six chapters covering sockets. Those chapters look at Unix and internet domain sockets, along with server design and advanced sockets topics. The book wraps up with a chapter on each of terminals and pseudoterminals, with something of an oddly placed "Alternative I/O Models" chapter in between them. It's an interesting chapter, covering select(), poll(), epoll(), signal-driven I/O, and a few other topics, but it seems weird where it is.

There is more, of course, and looking at the detailed table of contents will fill out the list. One thing that stands out from the book is the vast size of the Linux/Unix API. It also points out some of the warts and historical cruft that is carried along in that API. Kerrisk is not shy about noting things like that where appropriate in the text: "In summary, System V message queues are often best avoided."

There were two specific topics that I looked forward to reading about but were only marginally covered by the book. The first is containers and namespaces, which are very briefly mentioned in a discussion of the flags to the clone() system call. A more puzzling omission is that there is almost no mention of the ptrace() system call. In the few places it does come up, readers are referred to the ptrace(2) man page.

There are certainly other parts of the Linux API that could have been covered, beyond the system call interface—sysfs, splice(), and perf come to mind—but Kerrisk undoubtedly needed to draw the line somewhere. Overall, he did an excellent job of that. Technical books, especially those covering Linux, have a tendency to get stale rather quickly, but TLPI shouldn't suffer from that as much as a kernel internals book would, for example. There should really only be additions down the road as the user-space API is maintained by the kernel developers "forever", but updates will presumably need to be made eventually.

There are a handful of additional complaints I could make about the book, but they are all quite minor, as were those mentioned above. The biggest nit is that the "asides" in the text, which are numerous, are really often much more than just asides. Each is set off from the rest of text, indented and rendered in a slightly smaller font (which is typographically a bit annoying to me), and are meant to contain additional information that is not necessarily critical to understanding the topic. In my experience, though, many of them might best have been worked into the main text. See what I mean about minor complaints?

This is a book that will be useful to application and system-level developers, primarily, but there is much of interest for others as well. Kernel hackers will find it useful to ensure their new feature (or fix) doesn't break the existing API. Programmers who are primarily targeting other Unix systems may also find it useful for making their code more portable. I found it to be extremely useful and expect to return to it frequently. Anyone who has an interest in programming for Linux will likely feel the same way.

Index entries for this article
KernelBooks


to post comments

Review: The Linux Programming Interface

Posted Jan 19, 2011 20:04 UTC (Wed) by b7j0c (guest, #27559) [Link]

i've been reading this and its an impressive work. i can only imagine the amount of effort that went into writing this...

Review: The Linux Programming Interface

Posted Jan 19, 2011 20:49 UTC (Wed) by mkerrisk (subscriber, #1978) [Link] (1 responses)

Note to readers of this review: there is a temporary glitch in the man7.org web page that points to the source code tarballs for TLPI. This should be fixed in about 24 hours, but in the meantime the correct location for the code can be found here.

Review: The Linux Programming Interface

Posted Jan 20, 2011 8:09 UTC (Thu) by mkerrisk (subscriber, #1978) [Link]

The links for the source code tarballs have now been corrected on man7.org.

Review: The Linux Programming Interface

Posted Jan 19, 2011 21:01 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (4 responses)

Wow! Thanks!

I sooooo needed a book like this that I even contemplated writing it myself.

/me waits for ebook.

Review: The Linux Programming Interface

Posted Jan 20, 2011 1:00 UTC (Thu) by dlang (guest, #313) [Link] (3 responses)

if you buy the book from the publisher, you will get the e-book version as well.

Review: The Linux Programming Interface

Posted Jan 20, 2011 12:55 UTC (Thu) by jku (subscriber, #42379) [Link] (1 responses)

Disappointing if the hard copies bought from other sellers don't include that...

Anyway, there's a coupon code on http://man7.org/tlpi/ that gives 30% off -- that makes the publisher price at least somewhat competitive with other shops.

Review: The Linux Programming Interface

Posted Jan 20, 2011 18:46 UTC (Thu) by mkerrisk (subscriber, #1978) [Link]

Quoting a just-posted blog entry:

Some days ago, No Starch Press started selling an ebook version of TLPI. The ebook is also provided for free when you buy a paper copy of TLPI from No Starch (look here for coupon—valid until end of February—that provides a publisher discount for the book+ebook package).

Currently, the ebook is available only in PDF form and only from No Starch. However, a full range of other ebook formats is currently in production, and when those formats are available they will be sold through the usual retail channels (and made available to No Starch customers who already have the ebook). I expect those other formats to be available around mid-February.

Review: The Linux Programming Interface

Posted Jan 20, 2011 14:00 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

I'm in Ukraine and shipping options are limited and costly. Also, I don't like physical books because I move quite frequently.

Review: The Linux Programming Interface

Posted Jan 19, 2011 21:35 UTC (Wed) by andikleen2 (guest, #52506) [Link]

Yes it's a very nice book. I expect it to become the "Stevens" of Linux low level programming.

-Andi

Review: The Linux Programming Interface

Posted Jan 19, 2011 21:47 UTC (Wed) by dougg (guest, #1894) [Link]

As pointed out in the preface of the book, its format is homage to the late Richard Stevens who wrote a great series of books on Unix and TCP/IP programming in the 1990s. After carrying around TLPI for several weeks I am beginning to think that dividing TLPI into several volumes (like Richard Stevens did) would be a good idea.
Having fought with System V IPC I think that I'll skim the IPC sections. Besides I use inotify, flock and tmpfs to cover my current IPC needs. And TLPI is the first book that I have seen to cover those three subjects.

Review: The Linux Programming Interface

Posted Jan 20, 2011 0:26 UTC (Thu) by Nick (guest, #15060) [Link]

I have a copy of this, and I would recommend it for userspace programmers using the Linux kernel API and also kernel programmers implementing it.

It's huge, but each particular section is well split up, so they are digestible chunks. Those parts I have read so far are interesting and informative.

Review: The Linux Programming Interface

Posted Jan 20, 2011 7:16 UTC (Thu) by alison (subscriber, #63752) [Link] (4 responses)

LWN needs a "buy now" button so that we can help support the site with book purchases.

It's worth mentioning Matthew and Stones' _Beginning Linux Programming_ while on this topic. That book is a few years older and obviously less encyclopedic but nonetheless a wonderful and more portable reference. I particularly love that M&S include examples of bad code and bad practices in using the C API. I have learned the answers to several long-time puzzlements by typing in their examples and picking them apart. While I read the M&S book in order of my curiosity, I'm pretty sure I have now covered pretty much the whole multi-hundred page volume. As with any good bible, those so inclined can always while away 5 minutes by opening M&S to a random page.

Unfortunately it sounds like I need the Kerrisk book too: sigh.

"Buy now"

Posted Jan 20, 2011 14:00 UTC (Thu) by corbet (editor, #1) [Link] (3 responses)

Almost exactly a year ago we were dipping our toes back into the affiliate scene so we could provide just such a button. Then this happened. I can only say that we were quite glad not to be dependent on that revenue stream...

"Buy now"

Posted Jan 20, 2011 15:14 UTC (Thu) by rriggs (guest, #11598) [Link]

Amazon ain't the only game in town...

"Buy now"

Posted Jan 20, 2011 16:32 UTC (Thu) by alison (subscriber, #63752) [Link] (1 responses)

"Buy now" from No Starch or O'Reilly or other FLOSS-friendly presses certainly seems safer. Why not ThinkGeek LWN t-shirts to support the site too? Or Flattr buttons, maybe? Easy for me to propose a whole list of improvements for other to implement, as always! I bought the Kerrisk book last night (and another at the same time) and am sorry LWN doesn't get a cent.

"Buy now"

Posted Jan 20, 2011 16:48 UTC (Thu) by jake (editor, #205) [Link]

> Why not ThinkGeek LWN t-shirts to support the site too?

these we have (though not from ThinkGeek): http://www.cafepress.com/lwn_net

jake

Review: The Linux Programming Interface

Posted Jan 20, 2011 17:39 UTC (Thu) by RobSeace (subscriber, #4435) [Link] (14 responses)

> 57.6 The Linux Abstract Socket Namespace

I'm delighted to see this listed in the table of contents... This is a criminally underdocumented and seemingly little known feature... I really wish all apps that use a Unix domain socket would use an abstract name instead of a real filesystem name, requiring yet another stupid "/tmp" directory be created to hold it, or whatever... Unix domain sockets within the filesystem are just ugly clutter, and serve no useful purpose... The abstract namespace is a brilliant concept, which I wish all other Unices would steal...

Review: The Linux Programming Interface

Posted Jan 20, 2011 18:49 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (13 responses)

And I happen to have quite the opposite opinion. For example, real filesystems allow me to use "lsof" to check the list of socket's clients. Or to use common Unix permissions to control access.

Review: The Linux Programming Interface

Posted Jan 20, 2011 19:15 UTC (Thu) by RobSeace (subscriber, #4435) [Link] (12 responses)

"lsof -U" will list all Unix domain sockets, including those in the abstract namespace... It would be nice if it displayed the actual abstract name in a format similar to "/proc/net/unix", and allowed searching for them by that name as well, I agree... But, that's more a shortcoming of lsof than of abstract Unix domain sockets...

And, using filesystem permissions to control access of Unix domain sockets is highly unportable... Many systems totally ignore perms on Unix domain sockets, making them effectively always 0777, like symlinks... (Yes, of course, the abstract namespace is also unportable, so relying on one Linux quirk is as good/bad as relying on another, I suppose...) But, any sane app that needs to restrict who talks to it over a Unix domain socket will use a much better app-level restriction of some kind, probably using SO_PEERCRED or SCM_CREDENTIALS/SO_PASSCRED or something of the sort, if not a full-blown login/authentication mechinism...

Review: The Linux Programming Interface

Posted Jan 20, 2011 19:20 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (7 responses)

>But, that's more a shortcoming of lsof than of abstract Unix domain sockets...

That's not a shortcoming of lsof, but a shortcoming of having a separate namespace. It goes against all the Unix traditions.

While we're at it, why not move /dev into a separate namespace (like Windows does, BTW)? And then /sys and /proc.

Well, personally I don't care about other Unixes. However, ability to use AppArmor to restrict access to sockets somehow makes me feel more secure.

Review: The Linux Programming Interface

Posted Jan 20, 2011 20:10 UTC (Thu) by RobSeace (subscriber, #4435) [Link] (6 responses)

> That's not a shortcoming of lsof, but a shortcoming of having a separate
> namespace. It goes against all the Unix traditions.

Not when it comes to sockets, it doesn't... Do your TCP and UDP sockets exist in the filesystem, as well? How do you think lsof deals with those? Right, it has to deal with a separate namespace... Just like it should be taught how to do with Linux's abstract Unix domain namespace... It's not like it's hard: they're right there in "/proc/net/unix", which it already reads anyway...

What, aside from lsof, actually needs to ever reference a Unix domain socket by pathname as if it were a file, anyway? It's not like you can just pass one to an arbitrary app which is expecting a file, and expect it to do anything sensible... Like, for instance, you can do with a named pipe... That's a case where existing in the filesystem is actually useful... There's absolutely no use to socket files; they're not "files" in any meaningful sense, because you can't do file I/O on them... They're just special creatures that happen to be identified via a pathname...

And, your strawman about getting rid of "/dev", "/sys", "/proc", etc. is missing the point entirely... The things under those dirs are perfectly usable AS FILES! They may be special creatures of their own, but plain old file I/O works on them; you can open() them, read() from them, write() to them... You can't do that on a socket "file"... I'm all in favor of "everything as a file", having used Unix-like systems for well over 20 years now... But, I'm not in favor of leaving tons of file-like tokens scattered all over the filesystem, which can't actually be used like files for anything, and which only exist there for the sole purpose of having a unique name to identify them by...

Review: The Linux Programming Interface

Posted Jan 20, 2011 20:21 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (5 responses)

>Not when it comes to sockets, it doesn't... Do your TCP and UDP sockets exist in the filesystem, as well? How do you think lsof deals with those?

Which is a shortcoming of Unix design (which was fixed in 9p, btw).

>What, aside from lsof, actually needs to ever reference a Unix domain socket by pathname as if it were a file, anyway? It's not like you can just pass one to an arbitrary app which is expecting a file, and expect it to do anything sensible...

How about security with AppArmor? Does your namespace work with chroot? Also, unix sockets have a creation time (which helped me once).

>And, your strawman about getting rid of "/dev", "/sys", "/proc", etc. is missing the point entirely... The things under those dirs are perfectly usable AS FILES!

Not really. I can't open a lot of files in /proc for writing or reading. Quite a lot of devices in /dev are IOCTL-only and can't perform any read/write operation and so on.

Review: The Linux Programming Interface

Posted Jan 20, 2011 21:08 UTC (Thu) by RobSeace (subscriber, #4435) [Link] (4 responses)

> Which is a shortcoming of Unix design

Perhaps, but given that you need to use completely different syscalls to work with sockets, and can't really just use regular file syscalls on them (well, for the most part; of course you can use read()/write() on them), I'm not sure I agree... How does Plan9 deal with this? Can you just open() up a TCP socket, and somehow specify a host and port to connect to, or one to listen on? (A la bash's "/dev/tcp"...) Once you do, does this process-specific socket exist as a separate file for others to see (and interact with)? I'm not sure I see how it makes much sense, in general...

> How about security with AppArmor?

Maybe, I know nothing about AppArmor... My distro (RHEL/CentOS) doesn't use it, favoring SELinux instead... (And, there's probably SOME method of making SELinux work with abstract Unix domain sockets, but goodness knows if anyone could ever figure out HOW!)

> Does your namespace work with chroot?

My namespace? Thanks for the credit, but I didn't invent it; I'm just a very big fan of it who regularly uses it... ;-)

But, sure, I guess that's a possible valid use... I'm not sure I can really conceive of a real-world use for such a thing, however... Maybe sandboxing something with its own private "/dev/log" that goes somewhere other than the real syslogd? *shrug*

> Also, unix sockets have a creation time (which helped me once).

Well, not really; like any other file, they've got modify and change times... But, yeah, both will generally reflect creation time... I'm not really sure how that'd be of much help in general, though?

> I can't open a lot of files in /proc for writing or reading.

Like which? For reasons other than permissions? Not talking about directories (or symlinks to them), I assume? Do you mean the non-file FD symlinks under "/proc/#/fd/"? Those you can at least readlink() like a real symlink...

> Quite a lot of devices in /dev are IOCTL-only and can't perform any read/write operation and so on.

Is it really a lot? Even if so, at least you can open() them... And, at least all the device special files are confined to "/dev" (in practice), rather than scattered wherever (usually in "/tmp") like most filesystem Unix domain sockets... If they had their own directory to live in which everyone used by convention, I wouldn't mind them nearly as much... I don't mind "/dev/log", since it's stuck in "/dev/" with the other special files...

One huge benefit of abstract Unix domain sockets is no need to worry about unlink()'ing them when you're done, and dealing with the race conditions inherent in that... They just go away when you exit or close() the listening socket... With filesystem sockets, a server needs to see if the socket already exists in the filesystem; if so, maybe that means another copy of itself (or some other app) is using that socket; or, maybe it means it previously crashed before being able to remove that socket... Should it unlink() it and try to bind() it itself? Only way to know is try to connect() to it, and see if someone is really listening on it (or look for it in "/proc/net/unix")... None of this is needed with abstract Unix domain sockets...

Review: The Linux Programming Interface

Posted Jan 21, 2011 15:00 UTC (Fri) by price (guest, #59790) [Link] (2 responses)

The reason abstract-namespace sockets are evil is that everything you end up wanting to do to them has to be reinvented, or else you live without. If on the other hand you use a common abstraction, namely the filesystem, then you get the benefit of all the common tools.

Cyberax's examples of the things you want to do include
* protect with AppArmor
* hide in a namespace away from some processes (like with chroot)
* see when they were created (presumably for debugging)

Here's my example:
* move them out of the way.
You think you wouldn't want that for a socket? Think again. I once had to deal with a buggy server process (clvmd) that would occasionally hang unkillably (due to a kernel bug), while holding an abstract-namespace socket. This means that when I tried to restart it, the new process would immediately fail because the socket was already bound.

If the clvmd authors had used filesystem sockets like good Unix-respecting developers, I could have simply mv'd or even rm'd the old socket, and the new process would have been free to bind to its socket at the usual name. Instead, I had to restart the box. This was a VM server -- dozens of people's VMs were affected by each restart. The bug recurred a couple of times a day. I *really* wished the program had used sockets in the filesystem, or that somebody had implemented rename() or unlink() for abstract-namespace sockets -- but who would do that? The program should have used sockets in the filesystem.

If you're unhappy because a system leaves files around in /tmp that aren't used anymore, you're really focusing on the wrong things.

Review: The Linux Programming Interface

Posted Jan 21, 2011 15:39 UTC (Fri) by RobSeace (subscriber, #4435) [Link] (1 responses)

> examples of the things you want to do include

No, I want to do none of those things... Maybe they are things YOU and others want to do... But, personally, I have no need for any of them, and they mostly seem like stretches and grasping at straws to justify them existing in a place they certainly don't belong (the filesystem)...

And, your example of a buggy app and/or kernel is just crazy... You want to be able to kluge around a serious app/kernel bug by stealing its socket out from under it, and replacing it via another running copy? How about just fixing the bug! What if it were holding a TCP port# instead? Do you complain that you can't "rm" listening TCP ports, too?

> If you're unhappy because a system leaves files around in /tmp that aren't used anymore

That's part of why I dislike them... They're scattered around wherever, often somewhere under "/tmp" (which is a really poor place for something designed to be a shared identifier for communication between multiple apps)... But, mostly I dislike them because THEY ARE NOT FILES! Just having them exist as a directory entry in the filesystem does not fulfill some Unix utopia idea of "everything is a file"... In order for that to be fulfilled, the things must actually be usable AS FILES... If they were designed such that you could pass one to an otherwise unsuspecting app, which just open()'d it normally, and that magically let that app talk to whoever is listening on the other end of the socket (a la a named pipe), then I'd be all in favor of them... That would be brilliant... But, no, you can't do that... All you can do with a Unix domain socket "file" is to bind() to it or connect() to it... They're not files; they're filesystem representations of unique socket addresses, and that's all... As such, there's no need for them to live in the filesystem at all... (Unless you have special rare needs like those previously mentioned which can only be solved by them having a pathname in the filesystem...)

Review: The Linux Programming Interface

Posted Jan 27, 2011 14:14 UTC (Thu) by renox (guest, #23785) [Link]

> that if it were holding a TCP port# instead? Do you complain that you can't "rm" listening TCP ports, too?

I had this need in one of our application, to workaround an issue I had to use a small tool which can 'force close' a 'listening TCP ports', having the possibility to 'rm' listening TCP ports would have been much more easy.

Review: The Linux Programming Interface

Posted Jan 28, 2011 21:32 UTC (Fri) by spitzak (guest, #4593) [Link]

> And, at least all the device special files are confined to "/dev" (in practice), rather than scattered wherever (usually in "/tmp") like most filesystem Unix domain sockets...

I think this is your only legitimate complaint. Why not make a fix so the "abstract name space" is mounted under a permanent name. Then everything is in a predictable place in the filesystem, and you have all the HUGE advantages that they are in the same namespace you can search with existing tools.

/proc is full of files that used to be "namespaces" (actaully various kernel calls and tools that peeked into kernel memory maps). I think it is pretty obvious that /proc is VASTLY superior to the old api, in that it is discoverable and many more tools are written to use it.

Review: The Linux Programming Interface

Posted Jan 21, 2011 14:13 UTC (Fri) by cras (guest, #7000) [Link] (3 responses)

What systems ignore filesystem permissions on UNIX sockets? I doubt any that still matter (Linux, OSX, BSDs, Solaris).

Review: The Linux Programming Interface

Posted Jan 21, 2011 14:54 UTC (Fri) by RobSeace (subscriber, #4435) [Link] (1 responses)

As far as I know, most BSD derived ones do... Maybe the modern BSDs have added support for Unix domain file permissions, but it certainly wasn't historically true... I know I've heard of Solaris/SunOS ignoring Unix domain file perms before, as well... From "man 7 unix" on a Linux box:

In the Linux implementation, sockets which are visible in the filesys-
tem honour the permissions of the directory they are in. Their owner,
group and their permissions can be changed. Creation of a new socket
will fail if the process does not have write and search (execute) per-
mission on the directory the socket is created in. Connecting to the
socket object requires read/write permission. This behavior differs
from many BSD-derived systems which ignore permissions for Unix sock-
ets. Portable programs should not rely on this feature for security.

Review: The Linux Programming Interface

Posted Jan 21, 2011 15:05 UTC (Fri) by cras (guest, #7000) [Link]

Looking at http://www.cvedetails.com/cve/CVE-1999-1402/ I think this got fixed about 10 years ago everywhere. And since there aren't any other portable solutions for this either, I think it's safe enough nowadays to trust the filesystem permissions.

Review: The Linux Programming Interface

Posted Jan 25, 2011 9:47 UTC (Tue) by paulj (subscriber, #341) [Link]

Solaris 10 does. I doubt it's changed, but havn't checked recent versions of OpenSolaris.


Copyright © 2011, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds