DaemonForums  

Go Back   DaemonForums > OpenBSD > OpenBSD General

OpenBSD General Other questions regarding OpenBSD which do not fit in any of the categories below.

Reply
 
Thread Tools Display Modes
  #1   (View Single Post)  
Old 27th August 2022
yezster yezster is offline
Port Guard
 
Join Date: Jan 2014
Posts: 17
Default Is there a way to not clear the /tmp during boot up?

Greetings Everyone,

Is there a way to not clear the /tmp directory during boot up in OpenBSD?

Been trying to search for howtos in Duck to no success...


Thanks much,
y
Reply With Quote
  #2   (View Single Post)  
Old 27th August 2022
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,977
Default

Review your requirement, as it is not best practice.

To accomplish this requires you to locally modify your system's rc(8) script, /etc/rc. You would then need to merge your local changes into the OS's revised and updated /etc/rc script each time you upgrade the OS.
Reply With Quote
  #3   (View Single Post)  
Old 27th August 2022
jmccue jmccue is offline
Real Name: John McCue
Package Pilot
 
Join Date: Aug 2012
Location: here
Posts: 167
Default

IIRC, /var/tmp may not be cleared. I see vi recovery files are stored there, so I kind of doubt OpenBSD clears that dir out.

So you can try and set TMPDIR to /var/tmp and see if that works for you. Maybe create a file there, reboot and see what happens ?
__________________
[t]csh(1) - "An elegant shell, for a more... civilized age."
- Paraphrasing Star Wars (tvtropes.org)
Reply With Quote
  #4   (View Single Post)  
Old 27th August 2022
J65nko J65nko is offline
Administrator
 
Join Date: May 2008
Location: Budel - the Netherlands
Posts: 4,128
Default

No, using /var/tmp will not be a solution ...
Code:
$ uname -a ; ls -l /var/tmp

OpenBSD lenap.utp.xnet 7.1 GENERIC.MP#3 amd64
lrwxrwx---  1 root  wheel  6 Apr 12 01:45 /var/tmp -> ../tmp
There is a vi.recover in /tmp:
Code:
$ ls -l /tmp  
drwx------  2 adriaan  wheel  512 Aug 27 23:07 Temp-9e0e9ddd-e8ac-47d6-92cd-3529f09a94b1
srwxrwxrwx  1 adriaan  wheel    0 Aug 27 23:07 dbus-HVD68o9dov
drwx------  2 adriaan  wheel  512 Aug 27 23:06 ssh-9tK1IwOtsHFc
drwxrwxrwt  2 root     wheel  512 Aug 26 13:41 vi.recover
The lines in the /etc/rc startup scrip show that not all files in the tmp directory will be rm'ed::
Code:
   550  echo clearing /tmp
   551  
   552  # Prune quickly with one rm, then use find to clean up /tmp/[lqv]*
   553  # (not needed with mfs /tmp, but doesn't hurt there...).
   554  (cd /tmp && rm -rf [a-km-pr-uw-zA-Z]*)
   555  (cd /tmp &&
   556      find . -maxdepth 1 ! -name . ! -name lost+found ! -name quota.user \
   557          ! -name quota.group ! -name vi.recover -execdir rm -rf -- {} \;)
The last 3 lines exempt directory /tmp/vi.recover from being deleted.

EDIT:
A little more further in that script:
Code:
   593  echo 'preserving editor files.'; /usr/libexec/vi.recover
So it runs /usr/libexec/vi.recover, which is a Perl script that recreates the vi recover directory if it does not exist and also sanitizes the files in that directory.
You can read it with $ cat -n /usr/libexec/vi.recover | less
__________________
You don't need to be a genius to debug a pf.conf firewall ruleset, you just need the guts to run tcpdump

Last edited by J65nko; 27th August 2022 at 09:45 PM. Reason: Added remark about vi.recover Perl script
Reply With Quote
  #5   (View Single Post)  
Old 27th August 2022
yezster yezster is offline
Port Guard
 
Join Date: Jan 2014
Posts: 17
Default

Thanks for putting this to my attention...

Now I know that vi.recover within /tmp is exempted from getting cleared during boot up.

So now I'm using it to store my temporary files.
Reply With Quote
  #6   (View Single Post)  
Old 27th August 2022
J65nko J65nko is offline
Administrator
 
Join Date: May 2008
Location: Budel - the Netherlands
Posts: 4,128
Default

I don't quite completely understand the /usr/libexec/vi.recover Perl script. But it looks like it t will delete some files that don't look like a regular recovery file for vi.
Code:
    71          # Delete anything that is not a regular file as that is either
    72          # filesystem corruption from fsck or an exploit attempt.
    73          # Real vi recovery files are created with mode 0600, ignore others.
    74          #
    75          if (!stat(RECFILE)) {
    76                  warn "$0: can't stat $file: $!\n";
    77                  close(RECFILE);
    78                  next;
    79          }
    80          if (((stat(_))[2] & 07777) != 0600) {
    81                  close(RECFILE);
    82                  next;
    83          }
    84          my $owner = (stat(_))[4];
    85          if (! -f _ || ! -s _) {
    86                  unlink($file) unless -d _;
    87                  close(RECFILE);
    88                  next;
    89          }
I don't undestand lines 85 and 86, that deletes a file.

To test I created some files"
Code:
adriaan@lenap[/tmp/vi.recover]ls -l
-rw-------  1 adriaan  wheel  19 Aug 28 01:08 mode600file
-rw-r--r--  1 adriaan  wheel  15 Aug 28 01:07 mode644file
-rw-------  1 root     wheel  15 Aug 28 01:11 root-mode600file
After a reboot the files are still there:
Code:
adriaan@lenap[/tmp/vi.recover]ls -l
-rw-------  1 adriaan  wheel  19 Aug 28 01:08 mode600file
-rw-r--r--  1 adriaan  wheel  15 Aug 28 01:07 mode644file
-rw-------  1 root     wheel  15 Aug 28 01:11 root-mode600file
__________________
You don't need to be a genius to debug a pf.conf firewall ruleset, you just need the guts to run tcpdump

Last edited by J65nko; 28th August 2022 at 12:01 AM.
Reply With Quote
  #7   (View Single Post)  
Old 28th August 2022
yezster yezster is offline
Port Guard
 
Join Date: Jan 2014
Posts: 17
Default

Thanks...

I also tried putting some files inside vi.recover and then reboot, then wallah! files are still there. But no worries since all these files I put inside there are just either duplicates or temporary files. I will not be putting crucial files inside there. I will try experimenting and observing /tmp/vi.recover from time to time and see how it behaves. Thanks so much for the heads up guys.
Reply With Quote
  #8   (View Single Post)  
Old 28th August 2022
TronDD TronDD is offline
Spam Deminer
 
Join Date: Sep 2014
Posts: 304
Default

Quote:
Originally Posted by J65nko View Post
I don't quite completely understand the /usr/libexec/vi.recover Perl script. But it looks like it will delete some files that don't look like a regular recovery file for vi.
It doesn't say it will delete files that don't look like regular recovery files. It says it will delete anything that don't look like regular files.

It first checks for mode 0600 and does nothing if the mode is not 0600. If it is, it only deletes it if it is not a file or is zero sized, and not a directory. Your tests were all files with contents.
Reply With Quote
  #9   (View Single Post)  
Old 28th August 2022
jmccue jmccue is offline
Real Name: John McCue
Package Pilot
 
Join Date: Aug 2012
Location: here
Posts: 167
Default

Quote:
Originally Posted by J65nko View Post
No, using /var/tmp will not be a solution ...
[code]$ uname -a ; ls -l /var/tmp
Thanks, that is what I get for checking

Another BSD did something like that when I used it many many years ago, never bothered to check OpenBSD.
__________________
[t]csh(1) - "An elegant shell, for a more... civilized age."
- Paraphrasing Star Wars (tvtropes.org)
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
US government agency destroys hardware to clear malware J65nko News 4 10th July 2013 03:05 PM
Not clear how to build a Jail with ezjail barti FreeBSD Security 13 11th September 2012 03:56 PM
Gnome - Clear Font in all applications openBSDheart OpenBSD Installation and Upgrading 4 13th September 2011 04:08 PM
HOWTO: Clear console screen after logout vermaden Guides 0 5th May 2008 11:30 AM


All times are GMT. The time now is 10:19 AM.


Powered by vBulletin® Version 3.8.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Content copyright © 2007-2010, the authors
Daemon image copyright ©1988, Marshall Kirk McKusick