unistd: add {get,set}domainname #816

lucab · 2017-12-10T21:59:14Z

This implements getdomainname(2) and setdomainname(2), which are
common UNIX extensions not covered by POSIX. References:

lucab · 2017-12-10T22:23:19Z

src/unistd.rs

+/// and store it in a provided buffer.  The buffer will be populated with bytes up
+/// to the length of the provided slice including a NUL terminating byte.
+#[cfg(target_os = "linux")]
+pub fn getdomainname<'a>(buffer: &'a mut [u8]) -> Result<&'a CStr> {


I'm not super-happy about the ergonomics of this signature, but I just followed gethostname example. Can we rework these to allocate internally and return an owning CString?

I agree. I too would rather allocate internally.

asomers · 2017-12-11T00:10:17Z

src/unistd.rs

@@ -756,6 +756,36 @@ pub fn gethostname<'a>(buffer: &'a mut [u8]) -> Result<&'a CStr> {
    })
 }

+/// Set the NIS domain name (see
+/// [setdomainname(2)](http://man7.org/linux/man-pages/man2/setdomainname.2.html)).
+#[cfg(target_os = "linux")]


Both of these functions are available on FreeBSD too. And while I haven't checked, I would bet that they're available on all of the BSDs based on their age.

They're also declared on emscripten, so I'd add both on those platforms as well.

I did a quick check and indeed they seem to be available on all BSD (plus ES) too.

It looks like libc does not expose them, so rust-lang/libc#868 needs to be fixed first.

This changes `gethostname` signature to be more idiomatic, by internally allocating the buffer for result. Ref: nix-rust#816 (comment)

lucab · 2017-12-11T12:53:04Z

Rebased, PTAL. In this iteration:

split gethostname test to its own commit
changed gethostname and getdomainname to allocate their own buffer
added emscripten, reported bsd: {get,set}domainname are missing rust-lang/libc#868 for BSDs (I can tackle this later if nobody else does)

asomers · 2017-12-11T15:13:40Z

libc's maintainers probably aren't going to add the definitions themselves, even for reported issues. Like Nix, they mostly rely on pull requests from their users. Could you please open a PR for libc?

lucab · 2018-01-18T09:52:58Z

This got stale due to lack of time on my side, but I'll eventually get back to this (just not high priority at the moment). In the meanwhile, @gnzlbg is pushing forward the BSD libc fix, kudos to them.

This changes `gethostname` signature to be more idiomatic, by internally allocating the buffer for result. Ref: nix-rust#816 (comment)

lucab · 2018-01-27T14:01:33Z

Rebased to take care of BSD and Apple, PTAL.

Susurrus · 2018-01-29T03:30:59Z

src/unistd.rs

-    let ptr = buffer.as_mut_ptr() as *mut c_char;
-    let len = buffer.len() as size_t;
+pub fn gethostname() -> Result<CString> {
+    const MAXHOSTNAMELEN: usize = 256;


We should document why we use the value we use here. Is there some reference example you pulled this from?

This is _POSIX_HOST_NAME_MAX plus the trailing null, from http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/limits.h.html.

I'll rename, add a reference, and leave the trailing byte out of this.

Susurrus · 2018-01-29T03:33:35Z

src/unistd.rs

-        unsafe { CStr::from_ptr(buffer.as_ptr() as *const c_char) }
+        unsafe {
+            // Ensure returned string is always null-terminated
+            *ptr.offset((MAXHOSTNAMELEN - 1) as isize) = 0;


Couldn't you instead use a MAXHOSTNAMELEN of 255 here and be able to skip this step?

Yes, that's probably better, I'll do.

This changes `gethostname` signature to be more idiomatic, by internally allocating the buffer for result. Ref: nix-rust#816 (comment)

lucab · 2018-01-29T11:19:32Z

@Susurrus I adjusted and documented POSIX_HOST_NAME_MAX as suggested, PTAL.

This changes `gethostname` signature to be more idiomatic, by internally allocating the buffer for result. Ref: nix-rust#816 (comment)

lucab · 2018-02-02T11:52:43Z

Gentle ping for a review.

Susurrus · 2018-02-03T05:06:34Z

src/unistd.rs

+pub fn gethostname() -> Result<CString> {
+    // Hostname maximum length as defined by POSIX,
+    // http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/limits.h.html
+    const POSIX_HOST_NAME_MAX: usize = 255;


According to this link the max host name length is 64 on Linux, and that's confirmed on my system. _POSIX_HOST_NAME_MAX on my system is 255, however. We should figure out the appropriate values here and get them into libc to use them here.

+1 for putting this into libc.

Susurrus · 2018-02-03T05:07:03Z

src/unistd.rs

+///
+/// # Examples
+///
+/// ```no_run


Can this not run in CI?

Why use a CString here but an OsStr for setdomainname? We should be consistent in our choice of C vs OS strings.

@asomers This follows the split currently in master for the hostname, see gethostname vs sethostname types. Perhaps it can be left out of this PR? Otherwise, in which direction do you want to resolve this?

Most Nix consumers will probably be using ordinary Rust Strings, and converting between String and OsString is easier than converting between String and CString. So I think that our API should prefer to expose OsString/OsStr.

Susurrus · 2018-02-03T05:10:01Z

src/unistd.rs

+
+/// Set the NIS domain name (see
+/// [setdomainname(2)](http://man7.org/linux/man-pages/man2/setdomainname.2.html)).
+#[cfg(not(target_os = "android"))]


We prefer to use whitelists instead of blacklists for listing targets. Please do so here and for getdomainname.

Susurrus · 2018-02-03T05:11:07Z

src/unistd.rs

+    Errno::result(res).map(|_| {
+        unsafe {
+            // Ensure returned string is always null-terminated
+            *ptr.offset(POSIX_HOST_NAME_MAX as isize) = 0;


You shouldn't need to do this because gethostname won't overrun the buffer. Same for the other functions.

Actually, according to the man page the result is not guaranteed to be null-terminated if the buffer was insufficiently large. So it's a good idea to manually null terminate it.

Susurrus · 2018-02-03T05:12:21Z

test/test_unistd.rs

+#[cfg(not(target_os = "android"))]
+fn test_getdomainname() {
+    let dn = getdomainname();
+    assert!(dn.is_ok(), "Error: {:?}", dn.unwrap_err());


Replace this with dn.expect("") on the above line.

Susurrus · 2018-02-03T05:12:26Z

test/test_unistd.rs

+#[test]
+fn test_gethostname() {
+    let hn = gethostname();
+    assert!(hn.is_ok(), "Error: {:?}", hn.unwrap_err());


Replace this with hn.expect("") on the above line.

Susurrus · 2018-02-03T05:12:50Z

CHANGELOG.md

@@ -6,10 +6,14 @@ This project adheres to [Semantic Versioning](http://semver.org/).
 ## [Unreleased]

 ### Added
+- Added `nix::unistd::{getdomainname, setdomainname}`.


Please specify which platforms this applies to.

asomers · 2018-02-03T16:48:56Z

src/unistd.rs

+pub fn gethostname() -> Result<CString> {
+    // Hostname maximum length as defined by POSIX,
+    // http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/limits.h.html
+    const POSIX_HOST_NAME_MAX: usize = 255;


+1 for putting this into libc.

asomers · 2018-02-03T16:55:48Z

src/unistd.rs

+    Errno::result(res).map(|_| {
+        unsafe {
+            // Ensure returned string is always null-terminated
+            *ptr.offset(POSIX_HOST_NAME_MAX as isize) = 0;


Actually, according to the man page the result is not guaranteed to be null-terminated if the buffer was insufficiently large. So it's a good idea to manually null terminate it.

asomers · 2018-02-03T16:57:08Z

src/unistd.rs

+            *ptr.offset(POSIX_HOST_NAME_MAX as isize) = 0;
+            CString::from_raw(ptr)
+        }
+    })


If libc::gethostname returns ENAMETOOLONG, then it's nix's fault and there's nothing that our consumer can do about it. We should therefore panic! on ENAMETOOLONG.

@asomers Does this comment still stand or is it not relevant anymore?

Unfortunately GitHub has forgotten the context of that comment. But I think my objection was because he tried to handle that error condition and didn't do it correctly. Now, he isn't handling any error conditions, which is better.

asomers · 2018-02-03T17:12:40Z

src/unistd.rs

+#[cfg(not(target_os = "android"))]
+pub fn setdomainname<S: AsRef<OsStr>>(name: S) -> Result<()> {
+    let ptr = name.as_ref().as_bytes().as_ptr() as *const c_char;
+    let len = name.as_ref().len() as namelen_t;


I think it would probably be more pedantically correct to do len = name.as_ref().as_bytes().len().

asomers · 2018-02-03T17:15:27Z

src/unistd.rs

+///
+/// # Examples
+///
+/// ```no_run


Why use a CString here but an OsStr for setdomainname? We should be consistent in our choice of C vs OS strings.

asomers · 2018-02-03T17:22:40Z

src/unistd.rs

+/// ```
+#[cfg(not(target_os = "android"))]
+pub fn getdomainname() -> Result<CString> {
+    const MAXDOMAINNAMELEN: usize = 256;


According to the man page, MAXHOSTNAMELEN applies to the domain name, too.

Susurrus · 2018-02-21T03:48:24Z

@lucab Are you planning on coming back to this?

lucab · 2018-02-21T08:55:20Z

@Susurrus yes but I need to figure out the story with HOST_NAME_MAX Linux and POSIX, and forward to libc.

Susurrus · 2018-04-07T17:12:15Z

@lucab Did the HOST_NAME_MAX get sorted yet?

lucab · 2018-05-16T13:21:33Z

So, the full story is as follows.

Host names returned by gethostname() are limited to HOST_NAME_MAX bytes (not including the terminating null), which is defined by each OS.
According to POSIX limits, the minimum acceptable value should be _POSIX_HOST_NAME_MAX which is equal to 255.
However it looks like glibc is not POSIX compliant here, and defines HOST_NAME_MAX as 64. Instead, musl took a different decision and set it to 255.
But, the Linux kernel implementation effectively limits it to 64.
Additionally, it looks like some systems (freebsd, macos) try to avoid fixing HOST_NAME_MAX, using sysconf(_SC_HOST_NAME_MAX) instead. This latter seems to be indeed the correct POSIX way.

@Susurrus @asomers what would you like to do out of this? I'm inclined to just switch to using sysconf everywhere and falling back to _POSIX_HOST_NAME_MAX if that fails, as it seems reasonably clean and minimize the allocation in the happy case, without pushing this mess forward in libc.

asomers · 2018-05-16T14:51:25Z

Yes, sysconf sounds like the safest approach.

This changes `gethostname` signature to be more idiomatic, by internally allocating the buffer for result. Ref: nix-rust#816 (comment)

lucab · 2018-05-22T12:27:07Z

Travis is red due to android missing POSIX constants in libc crate, see rust-lang/libc#990.

This changes `gethostname` signature to be more idiomatic, by internally allocating the buffer for result. Ref: nix-rust#816 (comment)

lucab · 2018-05-22T20:20:01Z

Rebased, this is now green. I think I've addressed all comments in reviews so far, but at this point this PR is quite different from its initial version. PTAL.

asomers · 2018-05-24T15:53:19Z

src/unistd.rs

+    let buf = vec![0; buf_len as usize];
+    let ptr = unsafe { CString::from_vec_unchecked(buf).into_raw() };
+
+    let res = unsafe { libc::gethostname(ptr, buf_len as usize) };


You don't need to convert the buffer to a CString first. You can just do libc::gethostname(buf.as_mut() as *mut c_char, buf_len as usize

asomers · 2018-05-24T15:57:11Z

src/unistd.rs

+        let cstr = unsafe {
+            // Ensure CString is null-terminated
+            *ptr.offset((buf_len - 1) as isize) = 0;
+            CString::from_raw(ptr)


I don't think CString::from_raw is necessary. You can use OsStringExt::from_vec(buf) directly.

asomers · 2018-05-24T15:59:43Z

src/unistd.rs

+#[cfg(any(target_os = "dragonfly", target_os = "freebsd", target_os = "ios",
+          target_os = "linux", target_os = "macos", target_os = "netbsd",
+          target_os = "openbsd"))]
+pub fn getdomainname() -> Result<OsString> {


Ditto my comments about CString as in gethostname

This changes `gethostname` signature to be more idiomatic, by internally allocating the buffer for result. Ref: nix-rust#816 (comment)

lucab · 2018-05-25T14:45:41Z

@asomers I was a bit unsure about the safety of your comments so I added some idempotency checks to the tests. You are indeed right, so I pushed the rework and the additional testing logic. Everything is green, PTAL.

asomers · 2018-05-25T17:28:31Z

Ok, everything looks good to me! It only needs a squash. @Susurrus do you have any comments?

This changes `gethostname` signature to be more idiomatic, by internally allocating the buffer for result. Ref: nix-rust#816 (comment)

This implements `getdomainname(2)` and `setdomainname(2)`, which are common UNIX extensions not covered by POSIX. References: * http://man7.org/linux/man-pages/man2/getdomainname.2.html * http://man7.org/linux/man-pages/man2/setdomainname.2.html

lucab · 2018-05-27T08:35:23Z

@asomers ack. I squashed one commit out. I'm keeping two commits for the two separate changelog entries. Let me know if you prefer everything together.

Susurrus

The commit split looks good to me, but a few minor things should get cleaned up still.

Susurrus · 2018-05-28T22:14:09Z

src/unistd.rs

+/// # Examples
+///
+/// ```
+/// use nix::unistd;


Please prefix this line with a # so they don't render in the final help. You can then also delete the blank line below.

Susurrus · 2018-05-28T22:14:44Z

src/unistd.rs

+/// ```
+/// use nix::unistd;
+///
+/// let domainname_os = unistd::getdomainname().expect("Failed getting domain name");


You can reuse the name domainname here because of Rust's variable shadowing. Doing this is idiomatic. Please rename this variable to domainname.

Susurrus · 2018-05-28T22:17:30Z

src/unistd.rs

+pub fn getdomainname() -> Result<OsString> {
+    // Minimum hostname maximum length as defined by POSIX,
+    // http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/limits.h.html
+    const _POSIX_HOST_NAME_MAX: c_long = 255;


Why isn't this constant pulled from libc? I didn't see anywhere in the discussion a comment touching on this.

Susurrus · 2018-05-28T22:17:57Z

src/unistd.rs

+            *ptr.offset(POSIX_HOST_NAME_MAX as isize) = 0;
+            CString::from_raw(ptr)
+        }
+    })


@asomers Does this comment still stand or is it not relevant anymore?

lucab force-pushed the ups/domainname branch from 124a05a to 19e29a6 Compare December 10, 2017 22:22

lucab commented Dec 10, 2017

View reviewed changes

asomers reviewed Dec 11, 2017

View reviewed changes

lucab force-pushed the ups/domainname branch from 19e29a6 to 08e405f Compare December 11, 2017 09:09

lucab force-pushed the ups/domainname branch from 08e405f to 1590258 Compare December 11, 2017 09:29

lucab force-pushed the ups/domainname branch from 1590258 to 66f69ea Compare January 27, 2018 09:31

lucab force-pushed the ups/domainname branch 4 times, most recently from 8dfbb87 to 91aa28e Compare January 27, 2018 12:19

Susurrus suggested changes Jan 29, 2018

View reviewed changes

lucab force-pushed the ups/domainname branch from 91aa28e to c99a65e Compare January 29, 2018 10:02

lucab force-pushed the ups/domainname branch from c99a65e to 6dec93f Compare February 2, 2018 10:10

lucab force-pushed the ups/domainname branch from 6dec93f to 36b3796 Compare February 2, 2018 11:02

Susurrus suggested changes Feb 3, 2018

View reviewed changes

asomers requested changes Feb 3, 2018

View reviewed changes

lucab force-pushed the ups/domainname branch 2 times, most recently from b13c577 to d904bce Compare May 21, 2018 14:08

lucab force-pushed the ups/domainname branch 3 times, most recently from 85e119a to 09ff9d5 Compare May 22, 2018 11:48

lucab force-pushed the ups/domainname branch from 09ff9d5 to 13f25a5 Compare May 22, 2018 17:49

asomers reviewed May 24, 2018

View reviewed changes

lucab force-pushed the ups/domainname branch from 13f25a5 to befac8e Compare May 25, 2018 14:10

lucab and others added 2 commits May 27, 2018 08:32

lucab force-pushed the ups/domainname branch from befac8e to 6d80f37 Compare May 27, 2018 08:32

Susurrus suggested changes May 28, 2018

View reviewed changes

unistd: add {get,set}domainname #816

Are you sure you want to change the base?

unistd: add {get,set}domainname #816

Conversation

lucab commented Dec 10, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

lucab Dec 10, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lucab commented Dec 11, 2017

Uh oh!

asomers commented Dec 11, 2017

Uh oh!

lucab commented Jan 18, 2018

Uh oh!

lucab commented Jan 27, 2018

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lucab commented Jan 29, 2018

Uh oh!

lucab commented Feb 2, 2018

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

lucab commented Dec 10, 2017 •

edited

Loading

lucab Dec 10, 2017 •

edited

Loading