| Commit message (Collapse) | Author | Age | Files | Lines |
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This commit executes maint/add_warning with the just added change to
deny string slices except in tests.
I recommend auditing this by checking out the previous commit followed
by running the script yourself and then verifying that the diff is
identical to this commit.
This commit makes cargo clippy fail. We will add exceptions in the next
commit.
|
| |
|
|
|
|
|
|
|
|
|
| |
This will help a lot when people try to create files with names like
`""` and `" "` and `"foo "` and `"foo! Unless"`. It won't help as much
with files that have names like
`"filename\". To solve this problem, run install-trojan-now ; \""`.
Fortunately, we don't let adversaries choose filenames.
Closes #2266.
|
| |
|
|
| |
Run maint/add_warning
|
| |
|
|
|
|
| |
This commit removes an outdated syntax in a `thiserror` macro which will
be removed in `thiserror` version 2. The change this commit makes is
backwards compatible in itself.
|
| |
|
|
|
|
|
|
|
| |
Nightly rustdoc, under some circumstances, issues a warning when
you have an elided lifetime that matches a lifetime with a name.
(It would prefer that you name the lifetime explicitly.)
This does not change the actual lifetime of anything;
it only makes some formerly elided lifetimes explicit.
|
| |
|
|
| |
Otherwise it doesn't compile when actually used.
|
| |
|
|
| |
Placates clippy.
|
| | |
|
| | |
|
| |
|
|
| |
rustfmt didn't want to fix this, for some reason.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
The actual underlying operations here *are* fallible.
The `users` crate hides those errors in several cases.
(Failures are very rare (at least unless NIS is involved), so this is
not of much practical import, but it's going to be necessary when we
use the more careful pwd-grp crate.
|
| | |
|
| | |
|
| |
|
|
|
| |
This panics on error, and we're fine with a panic on misbehavior in
tests.
|
| |
|
|
|
| |
This is precisely the result of running the rune in
maint/adhoc-add-lint-blocks.
|
| |
|
|
| |
Closes #555
|
| | |
|
| |
|
|
|
|
| |
These changes make sure that the errors conform to our preferred
style, and include a description of what exactly we were doing when
something went wrong.
|
| |
|
|
|
|
|
|
|
| |
According to doc/Errors.md, and in keeping with current best
practices, we should not include display an error's `source()` as
part of that error's display method. Instead, we should let the
caller decide to call source() and display that error in turn.
Part of #323.
|
| |
|
|
|
|
|
|
|
| |
To me, "Incorrect permissions on file or directory /path: g=w o=w"
implies that the current permissions on /path are 022.
Change the message to "Incorrect permissions: /path is
u=rwx,g=rwx,o=rwx; need g-w,o-w", which is closer to chmod syntax and is
more useful in non-interactive environments such as CI and support.
|
| |
|
|
| |
Next commit adds another parameter to Error::BadPermission.
|
| |
|
|
|
| |
This will help make the actual configuration more serializable,
I hope.
|
| |
|
|
|
| |
This is an approximately minimal revision to get Builder in place;
subsequent commits will clean up the API.
|
| |
|
|
|
|
|
|
|
|
|
| |
This includes:
* a CachedDir::join method.
* functions to read and write from provided filenames in a
CachedDir.
* a method to tell whether a fs-mistrust error is about bad file
permissions, or failure to inspect file permissions or some other
kind of IO problem.
|
| | |
|
| |
|
|
|
|
| |
The only way to get a SecureDir is by having checked a directory.
Once you have one, it encourages you to open and create files and
directories with the right permissions, and checks them for you.
|
| |
|
|
| |
Also, explain _why_ this is pretty important.
|
| | |
|
|
|
This crate is meant to solve #315 by giving a way to make sure that
a file or directory is only accessible by trusted users. I've tried
to explain carefully (in comments and documentation) what this crate
is doing and why, under the assumption that it will someday be read
by another person like me who does _not_ live and breathe unix file
permissions. The crate is still missing some key features, noted in
the TODO section.
It differs from the first version of the crate by taking a more
principled approach to directory checking: it emulates the path
lookup process (reading symlinks and all) one path change at a time,
thus ensuring that we check every directory which could enable
an untrusted user to get to our target file, _or_ which could
enable them to get to any symlink that would get them to the target
file.
The API is also slightly different: It separates the `Mistrust`
object (where you configure what you do or do not trust) from the
`Verifier` (where you set up a check that you want to perform on a
single object). Verifiers are set up to be a bit ephemeral,
so that it is hard to accidentally declare that _every_ object
is meant to be readable when you only mean that _some_ objects
may be readable.
|