tor refuses to use /dev/null as a config file

sometimes it is useful to make sure tor does not load any values from a config file, and -f /dev/null is the default way to give it an empty one on linux.

Tor now refuses to use that as a file.

changed milestone to %Tor: unspecified

added component::core tor/tor integration lorax milestone::Tor: unspecified owner::cypherpunks points::.1 priority::medium reviewer::nickm severity::normal status::needs-revision type::enhancement version::tor 0.2.8.5-rc labels

To fix this, switch the function that loads the torrc from read_file_to_str to use read_file_to_str_until_eof instead. A patch would be welcome. This could be a good intro task.

Trac:
Points: N/A to .1
Milestone: N/A to Tor: 0.3.0.x-final
Keywords: N/A deleted, easy lorax integration added

Trac:
0001-Support-S_IFCHR-in-file_status.patch

It looks like this was actually failing because file_status does not currently support character special devices. The quickest fix was to just add support for this.

Trac:
Status: new to needs_review

Add 0.3.0 needs_review items (and ones that haven't been in needs_revision for very long) to review-group-10.

Trac:
Keywords: easy lorax integration deleted, lorax, integration, easy, review-group-10 added

The fix is correct here. Thanks cypherpunks!!!

However, it's missing a changes file. cypherpunks would you like to provide one? See here for info: https://gitweb.torproject.org/tor.git/tree/doc/HACKING/CodingStandards.md#n56

And also ideally provide a proper git branch, instead of a patches file?

Apart from that all is good here.

Trac:
Status: needs_review to needs_revision

Hmmm, thought about this some more.

The patch here does not whitelist /dev/null specifically. Instead, it makes file_status() accept any character device and return it as "a non-empty regular file, or a FIFO on unix-like systems". We use file_status() in various places in the codebase, like when opening/saving the torrc, or state files, or crypto keys.

I wonder if there are any operations that we can't do with a character device file that are required for the features above (like seek, or unlink, or whatever).

I did some tests by setting my state file and my consensus file to be a character device, and everything worked fine because Tor just replaced them. I'm just wondering if there is some crazy Unix thing that might bite us here. But I guess this can only occur if our users specify a character device file themselves, so that's OK.

I've reviewed this patch, and it seems simple enough, and trivially correct. And it does solve the problem in general for almost all files read by tor.

Trac:
Owner: N/A to cypherpunks
Status: needs_revision to assigned

Trac:
Status: assigned to needs_revision

Trac:
Keywords: review-group-10 deleted, N/A added

Trac:
0001-Support-S_IFCHR-in-file_status.2.patch

Revised patch to add changes file

Trac:
Status: needs_revision to needs_review

The changes file is not in the expected format. This can be verified with make check-changes.

The related code was introduced in commit 92acbe12bc9512100b9282d7e9d61fe86b5a60bb which is Tor version 0.0.2pre13.

Trac:
fixup.patch

Attached a fixup patch which changes the header to the expected format, adds a category, reflows the text, adds the ticket number in the expected format and adds the Tor version.

Trac:
Keywords: N/A deleted, review-group-14 added

Trac:
Reviewer: N/A to nickm

I think it would be much better to stop using file_status() whenever we don't absolutely have to do so. That's for a couple of reasons:

• The st_size field is not reliable on S_IFCHR devices, so anything that distinguishes between FN_EMPTY and FN_FILE will get the wrong answer.
• Generally, when we want to see whether we can read a file, it's better to just try to read the file and see what happens. To do otherwise invites race conditions. The only time when it makes sense to have a separate "does this file exist" check is when we aren't going to open the file.

Trac:
Status: needs_review to needs_revision

Trac:
Keywords: review-group-14 deleted, review-group-15 added

batch modify: I think these are "enhancement", though I could be wrong about some.

Trac:
Type: defect to enhancement

Trac:
Milestone: Tor: 0.3.0.x-final to Tor: 0.3.1.x-final

The poor cypherpunks who has been trying to help here for 8 months -- and the ticket still has the 'easy' tag? :)

0.3.1 feature freeze today: these don't seem like they will be all sorted out in time. Let's try to make progress in 0.3.2.

Trac:
Milestone: Tor: 0.3.1.x-final to Tor: 0.3.2.x-final

Trac:
Keywords: review-group-15 deleted, N/A added

Mark some needs_revision tickets as unspecified. If/when the revisions happen, they can go back into a live milestone.

Trac:
Milestone: Tor: 0.3.2.x-final to Tor: unspecified

Trac:
Keywords: easy deleted, N/A added

changed time estimate to 48m

moved to tpo/core/tor#19661 (closed)