@@ -495,18 +495,41 @@ pub fn temp_dir() -> PathBuf {
495
495
///
496
496
/// # Security
497
497
///
498
- /// This function should be used with care, as its incorrect usage can cause
499
- /// security problems. Specifically, as with many operations invovling files and
500
- /// paths, you can introduce a race condition. It goes like this:
501
- ///
502
- /// 1. You get the path to the current executable using `current_exe()`, and
503
- /// store it in a variable binding.
504
- /// 2. Time passes. A malicious actor removes the current executable, and
505
- /// replaces it with a malicious one.
506
- /// 3. You then use the binding to try to open that file.
507
- ///
508
- /// You expected to be opening the current executable, but you're now opening
509
- /// something completely different.
498
+ /// The output of this function should not be used in anything that might have
499
+ /// security implications. For example:
500
+ ///
501
+ /// ```
502
+ /// fn main() {
503
+ /// println!("{:?}", std::env::current_exe());
504
+ /// }
505
+ /// ```
506
+ ///
507
+ /// On Linux systems, if this is compiled as `foo`:
508
+ ///
509
+ /// ```bash
510
+ /// $ rustc foo.rs
511
+ /// $ ./foo
512
+ /// Ok("/home/alex/foo")
513
+ /// ```
514
+ ///
515
+ /// And you make a symbolic link of the program:
516
+ ///
517
+ /// ```bash
518
+ /// $ ln foo bar
519
+ /// ```
520
+ ///
521
+ /// When you run it, you won't get the original executable, you'll get the
522
+ /// symlink:
523
+ ///
524
+ /// ```bash
525
+ /// $ ./bar
526
+ /// Ok("/home/alex/bar")
527
+ /// ```
528
+ ///
529
+ /// This sort of behavior has been known to [lead to privledge escalation] when
530
+ /// used incorrectly, for example.
531
+ ///
532
+ /// [lead to privledge escalation]: http://securityvulns.com/Wdocument183.html
510
533
///
511
534
/// # Examples
512
535
///
0 commit comments