Feature #9842: system configuration variables (sysconf(), confstr(), pathconf() and fpathconf())

• Status: Closed
• Assignee: -
• Target version: -

[akr (Akira Tanaka)]

How about providing methods to obtain system configuration variables?

POSIX defines sysconf(), confstr(), pathconf() and fpathconf().
I implemented following methods in ext/etc.

• Etc.sysconf(name)
• Etc.confstr(name)
• IO.pathconf(name)
• IO#pathconf(name)

POSIX defines some names.
Various operating sysmtems define additional names.

They can be used as follows:

Etc.sysconf(Etc::SC_ARG_MAX) #=> 2097152
Etc.sysconf(Etc::SC_NPROCESSORS_ONLN) #=> 4
Etc.confstr(Etc::CS_PATH) #=> "/bin:/usr/bin"
Etc.confstr(Etc::CS_GNU_LIBC_VERSION) #=> "glibc 2.18"
IO.pathconf("/", Etc::PC_NAME_MAX) #=> 255
open("/") {|f| p f.pathconf(Etc::PC_TIMESTAMP_RESOLUTION) } #=> 1

I implemented them in ext/etc because I interpreted "etc" as
system configuration.

Any idea?

[kosaki (Motohiro KOSAKI)]

On Thu, May 15, 2014 at 7:45 AM, [e-mail] wrote:

Issue #9842 has been reported by Akira Tanaka.

---

Feature #9842: system configuration variables (sysconf(), confstr(), pathconf() and fpathconf())
https://bugs.ruby-lang.org/issues/9842

• Author: Akira Tanaka
• Status: Open
• Priority: Normal
• Assignee:
• Category:
• Target version:

---

How about providing methods to obtain system configuration variables?

POSIX defines sysconf(), confstr(), pathconf() and fpathconf().
I implemented following methods in ext/etc.

• Etc.sysconf(name)
• Etc.confstr(name)
• IO.pathconf(name)
• IO#pathconf(name)

POSIX defines some names.
Various operating sysmtems define additional names.

They can be used as follows:

Etc.sysconf(Etc::SC_ARG_MAX) #=> 2097152
Etc.sysconf(Etc::SC_NPROCESSORS_ONLN) #=> 4
Etc.confstr(Etc::CS_PATH) #=> "/bin:/usr/bin"
Etc.confstr(Etc::CS_GNU_LIBC_VERSION) #=> "glibc 2.18"
IO.pathconf("/", Etc::PC_NAME_MAX) #=> 255

Please drop this. This is broken by design. If an attacker create a
symlink which point
to FAT file system on the same place, IO.patchconf(PC_NAME_MAX) may return very
small size and might lead to security issue.

http://womble.decadent.org.uk/readdir_r-advisory.html

Or, at least, we need loooong document why you need much care about IO.pathconf.

open("/") {|f| p f.pathconf(Etc::PC_TIMESTAMP_RESOLUTION) } #=> 1

I implemented them in ext/etc because I interpreted "etc" as
system configuration.

Any idea?


---Files--------------------------------
sysconf-confstr-pathconf.patch (13 KB)


--
https://bugs.ruby-lang.org/

[akr (Akira Tanaka)]

Motohiro KOSAKI wrote:

Etc.sysconf(Etc::SC_ARG_MAX) #=> 2097152
Etc.sysconf(Etc::SC_NPROCESSORS_ONLN) #=> 4
Etc.confstr(Etc::CS_PATH) #=> "/bin:/usr/bin"
Etc.confstr(Etc::CS_GNU_LIBC_VERSION) #=> "glibc 2.18"
IO.pathconf("/", Etc::PC_NAME_MAX) #=> 255

Please drop this. This is broken by design. If an attacker create a
symlink which point
to FAT file system on the same place, IO.patchconf(PC_NAME_MAX) may return very
small size and might lead to security issue.

I see. I agree to drop IO.pathconf.

Is there a problem with sysconf(), confstr() and fpathconf()?

[akr (Akira Tanaka)]

• File sysconf-confstr-fpathconf.patch sysconf-confstr-fpathconf.patch added

Updated patch attached.
It doesn't define IO.pathconf.

[usa (Usaku NAKAMURA)]

I don't disagree with this feature, but can't you design a little more abstract interface?

[akr (Akira Tanaka)]

Usaku NAKAMURA wrote:

I don't disagree with this feature, but can't you design a little more abstract interface?

What the purpose of the abstraction?

For example, we can define Etc.getconf as a unified version of Etc.sysconf and Etc.confstr.
It is exepected to work as POSIX getconf command which can invoke sysconf and confstr.
getconf is an abstraction of sysconf and confstr because it includes the both functions.
Does this abstration help you?

[usa (Usaku NAKAMURA)]

POSIX is the standard which should be respected obviously, but Ruby is operating not only on POSIX environment.

Real needs is not revealing the items which getconf (or etc.) provides but the information along to a user's purpose, isn't it?
Whether do you want the information along to some use cases or getconf itself?
If the latter case, you can simply call getconf via system, `` or etc.
If the former case, I believe that you can determine a natural interface.

[akr (Akira Tanaka)]

I intend this feature (Etc.sysconf, etc.) as low level API.

One of the feature I want is Etc.confstr(Etc::CS_GNU_LIBC_VERSION).
I feel it is not a good idea to define a high level interface for it.

I like functions over command invocation.
Command invocation depends various fragile factors (PATH, etc.) and difficult to treat errors.

Of course, I agree some feature may be appropriate to be defined as high level interface.
People will find such feature more easily because
this feature makes low level features more visible.

[akr (Akira Tanaka)]

matz accepted this issue at https://bugs.ruby-lang.org/projects/ruby/wiki/DevelopersMeeting20140517Japan

[akr (Akira Tanaka)]

• Status changed from Open to Closed
• % Done changed from 0 to 100

Applied in changeset r45984.

---

• ext/etc/etc.c: Etc.sysconf, Etc.confstr and IO#pathconf implemented.

• ext/etc/extconf.rb: Check sysconf(), confstr() and fpathconf().

• ext/etc/mkconstants.rb: New file.

[ruby-core:62600] [Feature #9842]

[usa (Usaku NAKAMURA)]

Akira Tanaka wrote:

I intend this feature (Etc.sysconf, etc.) as low level API.

One of the feature I want is Etc.confstr(Etc::CS_GNU_LIBC_VERSION).
I feel it is not a good idea to define a high level interface for it.

I see.

I like functions over command invocation.
Command invocation depends various fragile factors (PATH, etc.) and difficult to treat errors.

Almost I can agree it.

Of course, I agree some feature may be appropriate to be defined as high level interface.
People will find such feature more easily because
this feature makes low level features more visible.

I was convinced by this explanation. Thank you.