single user question

classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

single user question

James Huddle
If the following questions trigger a sense of road rage, you may
safely assume they are not directed to you.

Is anyone running in single-user mode regularly?
Is anyone running a web server, for instance, in single-user mode?

Many thanks in advance.  Shields up.
-Jim
Reply | Threaded
Open this post in threaded view
|

Re: single user question

chohag
James Huddle writes:
> If the following questions trigger a sense of road rage, you may
> safely assume they are not directed to you.
>
> Is anyone running in single-user mode regularly?

I regularly boot things into single user mode to fix something or
otherwise engage in acts which could be confounded by running processes
holding resources open. I wouldn't say I regularly *run* in single-user
mode though.

> Is anyone running a web server, for instance, in single-user mode?

I am not and I can't see what the benefit could be - the kernel is
pretty good at process isolation. Assuming that you are asking because
you perceive benefits to doing so, I would be interested to know what
you think they are.

As you felt the need to begin with a defensive posture I shall end with
one; hopefully they will bookend that nonsense. This is not written in a
spirit of road rage but a spirit of enquiry.

Cheers,

Matthew

Reply | Threaded
Open this post in threaded view
|

Re: single user question

OpenBSD lists
In reply to this post by James Huddle
On 5/9/2019 9:21 AM, James Huddle wrote:
> If the following questions trigger a sense of road rage, you may
> safely assume they are not directed to you.
>
> Is anyone running in single-user mode regularly?
> Is anyone running a web server, for instance, in single-user mode?
>
> Many thanks in advance.  Shields up.
> -Jim
>

It is theoretically possible to do that, but you'd have to do -a lot-
of work to get it to do so.  It'd be much easier finding a proper
way to accomplish what you want without running single-user.

Single-user is meant as a fail-safe in case your system is too broken
to boot normally, but not so broken that you have to resort to bsd.rd
It lacks the ability to start any daemons that aren't run as root,
you'll have to manually mount your partitions (including remounting
root as R/W), networking isn't going to be configured yet, and even
when its up, you aren't going to have any security features turned on,
and just so much else you'd expect in an OS is going to be missing.

Reply | Threaded
Open this post in threaded view
|

Re: single user question

Troy Martin
In reply to this post by James Huddle
James Huddle on Thursday, May 9, 2019 9:22 AM:
> Is anyone running in single-user mode regularly?
> Is anyone running a web server, for instance, in single-user mode?

This reads a lot like one of those questions where someone asks how to do a
specific thing in a very specific way with a very specific tool, when the real
question they should be asking is how to do it more generally.

With that in mind, what are you actually trying to do?


--
Troy

Reply | Threaded
Open this post in threaded view
|

Re: single user question

chohag
In reply to this post by OpenBSD lists
Misc User writes:
> It is theoretically possible to do that, but you'd have to do -a lot-
> of work to get it to do so.  It'd be much easier finding a proper
> way to accomplish what you want without running single-user.

I wouldn't recommend using single user mode to do anything other than
repair but it's not true to say that doing so is a lot of work. /etc/rc
is only ~600 lines and a lot of that is unnecessary if the server is
going to run a single thing. In many cases you can probably get away
with just mount/fsck/pfctl/netstart.

There is actually no such thing as "single user mode". All there is is a
kernel which hasn't done anything yet, and everything OpenBSD's does as
it "enters multi-user mode" is described clearly and comprehensively in
/etc/rc. Duplicating what little of it you want is, literally, as simple
as copy-paste.

Matthew

Reply | Threaded
Open this post in threaded view
|

Re: single user question

OpenBSD lists
On 5/10/2019 1:28 AM, [hidden email] wrote:

> Misc User writes:
>> It is theoretically possible to do that, but you'd have to do -a lot-
>> of work to get it to do so.  It'd be much easier finding a proper
>> way to accomplish what you want without running single-user.
>
> I wouldn't recommend using single user mode to do anything other than
> repair but it's not true to say that doing so is a lot of work. /etc/rc
> is only ~600 lines and a lot of that is unnecessary if the server is
> going to run a single thing. In many cases you can probably get away
> with just mount/fsck/pfctl/netstart.
>
> There is actually no such thing as "single user mode". All there is is a
> kernel which hasn't done anything yet, and everything OpenBSD's does as
> it "enters multi-user mode" is described clearly and comprehensively in
> /etc/rc. Duplicating what little of it you want is, literally, as simple
> as copy-paste.
>
> Matthew
>
What I'm saying is that it would take far more work to get something
like httpd to run at that stage than it would take to make the changes
to a fully booted, and supportable, system.  Making changes to rc is
going to force the system's operator to make adjustments at every
system upgrade.

Besides, it is possible to build a very light-weight system to run a
single thing while still be secure and supportable.  I have a VM
template (Wel, a sitexx.tgz file) that just contains an rc.conf.local,
a new crontab, a syslogd.conf, and a few trivial scripts.  The system
weighs in at 8 MB of used RAM in normal operation and a load average of
zero.  It is also trivial to upgrade, has all its protections, and I can
remotely monitor it.  Took me two hours to build it, most of that spent
modifying copies of daily/weekly/monthly to output via syslog instead of
mail.


What I"m saying is that it takes less work overall to subtract from a
system in a supportable way than it is to try and handcraft an
unsupportable system.

Reply | Threaded
Open this post in threaded view
|

Re: single user question

James Huddle
>What I"m saying is that it takes less work overall to subtract from a
>system in a supportable way than it is to try and handcraft an
>unsupportable system.

If you know the supportable system well and your goal is only
a slight variation of that that system does, then that makes
perfect sense.

If, on the other hand, you are new to the system, and you
notice many examples of problems caused by what appears
to be the basic underpinnings of the system (things like
multiuser and TCP, itself, not to mention the open, welcoming
nature of open source), the kinds of things hard to avoid in a
modern OS,  then your argument is less convincing.

If what I've said sounds absurd or unsound, a calm reaction
might be, "try building you own OS!"  And I have tried, and it
is not trivial.  So I look for answers outside of that and of course
OpenBSD is the smallest, strongest, most popular alternative
(for people who seek a secure platform).

And I ask simple (sometimes *too* simple!) questions, and get
answers and move slowly forward.

What I am trying to do (thank you Troy Martin), is work through
the standard answers and missteps toward a more secure OS,
starting with OpenBSD and a flashlight.  It is my humble opinion
that the optimal number of users for (say) a laptop is one.
And the optimal number for a server is zero.  I doubt many would
agree with that assessment, but I'm looking for solutions, regardless.

And yes I do respect the decades and megahours that have gone
into Unix and OpenBSD, by people who are far superior to me
intellectually.  My flashlight is weak, but it still works.

Thanks to all (Rodrigo, esp.) for helping me to see straighter.

-Jim



On Fri, May 10, 2019 at 11:52 AM Misc User <[hidden email]>
wrote:

> On 5/10/2019 1:28 AM, [hidden email] wrote:
> > Misc User writes:
> >> It is theoretically possible to do that, but you'd have to do -a lot-
> >> of work to get it to do so.  It'd be much easier finding a proper
> >> way to accomplish what you want without running single-user.
> >
> > I wouldn't recommend using single user mode to do anything other than
> > repair but it's not true to say that doing so is a lot of work. /etc/rc
> > is only ~600 lines and a lot of that is unnecessary if the server is
> > going to run a single thing. In many cases you can probably get away
> > with just mount/fsck/pfctl/netstart.
> >
> > There is actually no such thing as "single user mode". All there is is a
> > kernel which hasn't done anything yet, and everything OpenBSD's does as
> > it "enters multi-user mode" is described clearly and comprehensively in
> > /etc/rc. Duplicating what little of it you want is, literally, as simple
> > as copy-paste.
> >
> > Matthew
> >
> What I'm saying is that it would take far more work to get something
> like httpd to run at that stage than it would take to make the changes
> to a fully booted, and supportable, system.  Making changes to rc is
> going to force the system's operator to make adjustments at every
> system upgrade.
>
> Besides, it is possible to build a very light-weight system to run a
> single thing while still be secure and supportable.  I have a VM
> template (Wel, a sitexx.tgz file) that just contains an rc.conf.local,
> a new crontab, a syslogd.conf, and a few trivial scripts.  The system
> weighs in at 8 MB of used RAM in normal operation and a load average of
> zero.  It is also trivial to upgrade, has all its protections, and I can
> remotely monitor it.  Took me two hours to build it, most of that spent
> modifying copies of daily/weekly/monthly to output via syslog instead of
> mail.
>
>
> What I"m saying is that it takes less work overall to subtract from a
> system in a supportable way than it is to try and handcraft an
> unsupportable system.
>
Reply | Threaded
Open this post in threaded view
|

Re: single user question

Raul Miller
On Wed, May 15, 2019 at 3:05 PM James Huddle <[hidden email]> wrote:
> What I am trying to do (thank you Troy Martin), is work through
> the standard answers and missteps toward a more secure OS,
> starting with OpenBSD and a flashlight.  It is my humble opinion
> that the optimal number of users for (say) a laptop is one.
> And the optimal number for a server is zero.  I doubt many would
> agree with that assessment, but I'm looking for solutions, regardless.

I'm going to try to phrase this politely, but I might trigger other
people to say some rude things (not sure if they'll be aimed at
myself, or not). Anyways...  I have two hypothetical questions you
should think about:

1) Why do you doubt that many would agree with that assessment?

2) Also, what is a "user"?

If by "user" you mean "person", that leads to some lines of discussion.

If by "user" you mean an integer value which appears under the label
"user_id" (or some variant, such as perhaps "uid") in a C structure,
that leads to other lines of discussion.

If by "user" you mean a line in the /etc/passwd file which identifies
a directory, that leads to yet other lines of discussion.

...

From skimming this thread, I don't think you mean any of those. But if
no one knows what you mean, it doesn't really matter whether they
agree or disagree with you.

Thanks,

--
Raul

Reply | Threaded
Open this post in threaded view
|

Re: single user question

Stefan R. Filipek
In reply to this post by James Huddle
If you have not already, be sure to read the 1975 paper "The
Protection of Information in Computer Systems" by Saltzer, et. al., at
least through section 1 A, for an introduction to computer security.

Reply | Threaded
Open this post in threaded view
|

Re: single user question

Ingo Schwarze
Hi,

Stefan R. Filipek wrote on Wed, May 15, 2019 at 05:20:04PM -0400:

> If you have not already, be sure to read the 1975 paper "The
> Protection of Information in Computer Systems" by Saltzer, et. al., at
> least through section 1 A, for an introduction to computer security.

Wow.  Some might feel offended when somebody, in 2019, asks them
to read a text written in 1975 in order to improve their understanding
of computer security.  That article predates a number of modern
mitigations contained in OpenBSD, including those in UNIX 32v (1979)
and in 3BSD (1980)...  ;-)

Then again, 10 years before he wrote this article, the author, Prof.
Dr. Jerry Salzer, while working on his Ph.D thesis, laid the crucial
foundations for the documentation system we are still using today,
so he appears to have a certain inclination towards creations of
lasting value:

  https://manpages.bsd.lv/history.html

Maybe i should read that article after all...  :-)

Yours,
  Ingo

Reply | Threaded
Open this post in threaded view
|

Re: single user question

Roderick

On Thu, 16 May 2019, Ingo Schwarze wrote:

> Wow.  Some might feel offended when somebody, in 2019, asks them
> to read a text written in 1975 in order to improve their understanding
> of computer security.

Or perhaps he should read this to get an idea of how to write an
init program:

https://people.eecs.berkeley.edu/~brewer/cs262/unix.pdf

I am not ashamed because I read it again from time to time. I am
not a system programer, and I like very much the simple way he
explains unix.

Rodrigo

Reply | Threaded
Open this post in threaded view
|

Re: single user question

James Huddle
In reply to this post by Raul Miller
First of all, I must say that it is with genuine gratitude that I read your
responses!

Moving on...
On Wed, May 15, 2019 at 3:05 PM James Huddle <[hidden email]>
wrote:
>> What I am trying to do (thank you Troy Martin), is work through
>> the standard answers and missteps toward a more secure OS,
>> starting with OpenBSD and a flashlight.  It is my humble opinion
>> that the optimal number of users for (say) a laptop is one.
>> And the optimal number for a server is zero.  I doubt many would
>> agree with that assessment, but I'm looking for solutions, regardless.

>I'm going to try to phrase this politely, but I might trigger other
>people to say some rude things (not sure if they'll be aimed at
>myself, or not). Anyways...  I have two hypothetical questions you
>should think about:

>1) Why do you doubt that many would agree with that assessment?
Probably the same reason that you would say "...I might trigger other
people to say some rude things..."  Often I feel that by merely stating
my opinion, here, I have opened the door to the proverbial darkroom.
Sorry!  That, and a multi-user system has been the heart and cornerstone
of Unix & co. for MILLENNIA.  That's fine.  But my laptop is not a 1985 VAX.
I just think that pushing the idea forward of using the most popular
multiuser OS in history - in single-user mode - might meet with a little
friction.

>2) Also, what is a "user"?
Good question.  I am a user.  Someone who has hacked into my multi-user
system as a different user is a user.  And apparently, so is the cups
daemon?

>If by "user" you mean "person", that leads to some lines of discussion.

>If by "user" you mean an integer value which appears under the label
>"user_id" (or some variant, such as perhaps "uid") in a C structure,
>that leads to other lines of discussion.

>If by "user" you mean a line in the /etc/passwd file which identifies
>a directory, that leads to yet other lines of discussion.

Although I have some understanding of the three discussions,
I feel that the "interchangeable parts" philosophy, which works great
for firearms technology, has created more problems than we should
be willing to accept in 21st century computing.  A user is *usually* a
human,
and might better be defined as an *owner*.  Not to be confused with
the thousands of visitors to a web site.

In short, If I am sitting at my laptop, no other humans should be
using my laptop at that time, without an arm-twisting amount of
authentication and my conscious awareness of said "other person".
Having a bunch of background processes doing human-user
things blurs that equation, unfavorably, IMO.
...

>From skimming this thread, I don't think you mean any of those. But if
>no one knows what you mean, it doesn't really matter whether they
>agree or disagree with you.

Hope that helps.
Weather's calling for rain.  Fingers crossed.
-Jim

On Wed, May 15, 2019 at 4:47 PM Raul Miller <[hidden email]> wrote:

> On Wed, May 15, 2019 at 3:05 PM James Huddle <[hidden email]>
> wrote:
> > What I am trying to do (thank you Troy Martin), is work through
> > the standard answers and missteps toward a more secure OS,
> > starting with OpenBSD and a flashlight.  It is my humble opinion
> > that the optimal number of users for (say) a laptop is one.
> > And the optimal number for a server is zero.  I doubt many would
> > agree with that assessment, but I'm looking for solutions, regardless.
>
> I'm going to try to phrase this politely, but I might trigger other
> people to say some rude things (not sure if they'll be aimed at
> myself, or not). Anyways...  I have two hypothetical questions you
> should think about:
>
> 1) Why do you doubt that many would agree with that assessment?
>
> 2) Also, what is a "user"?
>
> If by "user" you mean "person", that leads to some lines of discussion.
>
> If by "user" you mean an integer value which appears under the label
> "user_id" (or some variant, such as perhaps "uid") in a C structure,
> that leads to other lines of discussion.
>
> If by "user" you mean a line in the /etc/passwd file which identifies
> a directory, that leads to yet other lines of discussion.
>
> ...
>
> From skimming this thread, I don't think you mean any of those. But if
> no one knows what you mean, it doesn't really matter whether they
> agree or disagree with you.
>
> Thanks,
>
> --
> Raul
>
Reply | Threaded
Open this post in threaded view
|

Re: single user question

gwes-2


On 5/16/19 9:05 PM, James Huddle wrote:

> First of all, I must say that it is with genuine gratitude that I read your
> responses!
>
> Mov
> Probably the same reason that you would say "...I might trigger other
> people to say some rude things..."  Often I feel that by merely stating
> my opinion, here, I have opened the door to the proverbial darkroom.
> Sorry!  That, and a multi-user system has been the heart and cornerstone
> of Unix & co. for MILLENNIA.  That's fine.  But my laptop is not a 1985 VAX.
> I just think that pushing the idea forward of using the most popular
> multiuser OS in history - in single-user mode - might meet with a little
> friction.
>
I think this is where you are fatally confused.
>> 2) Also, what is a "user"?
> Good question.  I am a user.  Someone who has hacked into my multi-user
> system as a different user is a user.  And apparently, so is the cups
> daemon?
You are correct on the surface and very misled as to the underlying concept.

In Unixish parlance,

"single user" = a system running with no resource restrictions
    and all but the absolutely essential services and processes stopped

"multi user" = a system operating with normal division of privilege and
   resources and all normal services available.

A system in "single user" state is normally only accessed by one
person, for a short time, to perform vital maintenance.
In that state a mistake can destroy the system - even to make
the system unrecoverable, a "brick"

A "user" in the context of [multiprocess] computing is a label for
a set of privileges [access, execute, etc.] & resources [storage, etc.]
It can be assigned to a person, a functionality, a condition, or many
other concepts. This restriction is vital for normal operation.

Why?
No program can be guaranteed to be perfect, and no person can be guaranteed
to never make a mistake. By restricting what can be done by a process or
a person in a given situation, the consequences of an error, a bug,
or a deliberate intrusion can be minimized.

In order to be useful, your laptop must perform many tasks invisibly and
concurrently. To promote reliable operation, each task [process, thread,
etc]
is assigned resources and privileges. We hope that the set assigned to
each is sufficient but does not allow destruction [overwriting, renaming,
etc.] of resources necessary to other tasks or exposure of secrets.

The CUPS daemon can delete files. Do you want it to be able to delete
ANY file? It is given an identity [set of resources and privileges] to
print and otherwise manage ONLY the files YOU give it.

You can delete files. Do you want to be able to accidentally delete ANY
file? Or do you want to be able to write-protect some of them?

A prime example of a "single user" system according to your definition
is MSDOS. No restrictions on anything. How reliable is/was it?

A server may ordinarily have no people sitting at a console connected
to the machine. It may have hundreds or thousands of different identities
requesting service, none of which should be able to affect any other.
So it, by custom parlance, has hundreds of users.

You probably don't want to run your laptop in Unixish "single user"
since most of the services (graphics, networking, Bluetooth, etc.)
are not available and a simple typing error can erase every file on
the system.

I hope this brings you to an understanding of what the convention
of "single user" and "multi user" mean and why running, for instance,
your laptop in "single user" mode would make it useless for you.

geoff steckel

Reply | Threaded
Open this post in threaded view
|

Re: single user question

Roderick

On Fri, 17 May 2019, gwes wrote:

> You are correct on the surface and very misled as to the underlying concept.

You gave him an excellent answer. I hope many people read it.

He should just read the Unix paper I mentioned in other post. Not
the multiusersystem is a burden, bloat in modern unixoiudes.
It is a very simple and usefull concept.

> A prime example of a "single user" system according to your definition
> is MSDOS. No restrictions on anything. How reliable is/was it?

Well, that was not a good example. As far as I know, DOS was not
multitasking. If there may be many processes, then the idea of
classifying and restricting them follows immediately.

But what is the cause of this confussion? Most desktop systems,
the ones that perhaps the OP has in mind, are a big confuse bloat,
so that the simple unix idea is difficult to recognize in them.

Rodrigo

Reply | Threaded
Open this post in threaded view
|

Re: single user question

ropers
On 17/05/2019, Roderick <[hidden email]> wrote:
> As far as I know, DOS was not multitasking.

You're mostly correct, except there were task-switchers and there were
some multitasking-capable versions of DOS, notably Novell (ex-DR-) DOS
7. This was not very successful in the marketplace, in part because it
was late in DOS's life cycle*, but also because Microsoft engaged in
anticompetitive practices in that they deliberately engineered the
DOS-based Windows of the day to be incompatible with Novell's arguably
technically superior DOS flavour. This led to the "AARD" lawsuit --
which Microsoft settled for a cool 280 million dollars, as has since
been disclosed. And that was the end of that.

*though we may also ask if DOS's life cycle might have been extended
had DOS 7 succeeded

------------------------------------------------------------------------

> On Fri, 17 May 2019, gwes wrote:
>> "single user" = a system running with no resource restrictions
>>   and all but the absolutely essential services and processes stopped

>> A prime example of a "single user" system according to your definition
>> is MSDOS. No restrictions on anything. How reliable is/was it?

I think the OP inaccurately equated "single user" with single-task.
Correct me if I'm mistaken, but to my understanding, a Unix-like
system (to wit: OpenBSD) in "single user" mode is still multitasking,
albeit just between essential services.

------------------------------------------------------------------------

> On Fri, 17 May 2019, gwes wrote:
>> You can delete files. Do you want to be able to accidentally delete ANY
>> file? Or do you want to be able to write-protect some of them?

>> A prime example of a "single user" system according to your definition
>> is MSDOS. No restrictions on anything. How reliable is/was it?

In the history of the (Berkeley) Fast File System, has there ever been
an attempt to implement DOS-like undelete for FFS/UFS?
(I understand that for technical reasons, this could require running a
daemon that remembers just enough metadata to keep data recoverable so
long as it's not overwritten. I also understand that running a daemon
that remembers things nominally deleted would have security
implications, which may not keep me from running a daemond that w/o
being perfect could protect me from myself at least some of the time.)
I did find this:
https://lists.freebsd.org/pipermail/freebsd-questions/2016-May/271785.html
-- which didn't seem to suggest that the answer was any yessier now
than thirty years ago. So, that's a no, then? Anyone? Bueller?

On 17/05/2019, Roderick <[hidden email]> wrote:

>
> On Fri, 17 May 2019, gwes wrote:
>
>> You are correct on the surface and very misled as to the underlying
>> concept.
>
> You gave him an excellent answer. I hope many people read it.
>
> He should just read the Unix paper I mentioned in other post. Not
> the multiusersystem is a burden, bloat in modern unixoiudes.
> It is a very simple and usefull concept.
>
>> A prime example of a "single user" system according to your definition
>> is MSDOS. No restrictions on anything. How reliable is/was it?
>
> Well, that was not a good example. As far as I know, DOS was not
> multitasking. If there may be many processes, then the idea of
> classifying and restricting them follows immediately.
>
> But what is the cause of this confussion? Most desktop systems,
> the ones that perhaps the OP has in mind, are a big confuse bloat,
> so that the simple unix idea is difficult to recognize in them.
>
> Rodrigo
>
>

Reply | Threaded
Open this post in threaded view
|

Re: single user question

Nathan Hartman
On Fri, May 17, 2019 at 12:28 PM ropers <[hidden email]> wrote:

>
> In the history of the (Berkeley) Fast File System, has there ever been
> an attempt to implement DOS-like undelete for FFS/UFS?
> (I understand that for technical reasons, this could require running a
> daemon that remembers just enough metadata to keep data recoverable so
> long as it's not overwritten. I also understand that running a daemon
> that remembers things nominally deleted would have security
> implications, which may not keep me from running a daemond that w/o
> being perfect could protect me from myself at least some of the time.)
> I did find this:
> https://lists.freebsd.org/pipermail/freebsd-questions/2016-May/271785.html
> -- which didn't seem to suggest that the answer was any yessier now
> than thirty years ago. So, that's a no, then? Anyone? Bueller?


Maybe that could work for "normal delete" while making available a separate
"secure delete" that cannot be un-deleted and furthermore overwrites the
deleted data with random garbage. Administrators could optionally force the
secure overwrite delete.

>
Reply | Threaded
Open this post in threaded view
|

ffs undelete was: Re: single user question

gwes-2


On 5/17/19 2:34 PM, Nathan Hartman wrote:

> On Fri, May 17, 2019 at 12:28 PM ropers <[hidden email]> wrote:
>
>
> In the history of the (Berkeley) Fast File System, has there ever been
> an attempt to implement DOS-like undelete for FFS/UFS?
>
> Maybe that could work for "normal delete" while making available a separate
> "secure delete" that cannot be un-deleted and furthermore overwrites the
> deleted data with random garbage. Administrators could optionally force the
> secure overwrite delete.
>
I haven't looked at e.g. zfs in a long time.

A journal-like system which held the deleted/overwritten files
or a system of renaming wouldn't be *that* hard to instantiate
There are some problems:
(a) denial of service by writing and deleting huge [numbers, size] files.
(b) retention policy - under what conditions does the system
   guarantee existence of backup files?
(c) versioning - If I create & delete 'a' six times, how many copies are
held.
(d) cost of undelete operation - it's not clear how to make
      that efficient.

I'm sure people can find more.

A test version substituting a new open(2) and unlink(2) in libc would be
easy to make.

geoff steckel

Reply | Threaded
Open this post in threaded view
|

Re: ffs undelete was: Re: single user question

Edgar Pettijohn III-2

On May 17, 2019 3:14 PM, gwes <[hidden email]> wrote:

>
>
>
> On 5/17/19 2:34 PM, Nathan Hartman wrote:
> > On Fri, May 17, 2019 at 12:28 PM ropers <[hidden email]> wrote:
> >
> >
> > In the history of the (Berkeley) Fast File System, has there ever been
> > an attempt to implement DOS-like undelete for FFS/UFS?
> >
> > Maybe that could work for "normal delete" while making available a separate
> > "secure delete" that cannot be un-deleted and furthermore overwrites the
> > deleted data with random garbage. Administrators could optionally force the
> > secure overwrite delete.
> >
> I haven't looked at e.g. zfs in a long time.
>
> A journal-like system which held the deleted/overwritten files
> or a system of renaming wouldn't be *that* hard to instantiate
> There are some problems:
> (a) denial of service by writing and deleting huge [numbers, size] files.
> (b) retention policy - under what conditions does the system
>   guarantee existence of backup files?
> (c) versioning - If I create & delete 'a' six times, how many copies are
> held.
> (d) cost of undelete operation - it's not clear how to make
>      that efficient.
>
> I'm sure people can find more.
>
> A test version substituting a new open(2) and unlink(2) in libc would be
> easy to make.
>
> geoff steckel
>

I'm thinking something like a trashcan. Where rm(1) actually just moves the files to some predetermined location then on shutdown all files older than some configureable date are actually unlinked.

Edgar

Reply | Threaded
Open this post in threaded view
|

Re: ffs undelete was: Re: single user question

Solene Rapenne
In reply to this post by gwes-2
Le 2019-05-17 22:47, Edgar Pettijohn a écrit :

> On May 17, 2019 3:14 PM, gwes <[hidden email]> wrote:
>>
>>
>>
>> On 5/17/19 2:34 PM, Nathan Hartman wrote:
>> > On Fri, May 17, 2019 at 12:28 PM ropers <[hidden email]> wrote:
>> >
>> >
>> > In the history of the (Berkeley) Fast File System, has there ever been
>> > an attempt to implement DOS-like undelete for FFS/UFS?
>> >
>> > Maybe that could work for "normal delete" while making available a separate
>> > "secure delete" that cannot be un-deleted and furthermore overwrites the
>> > deleted data with random garbage. Administrators could optionally force the
>> > secure overwrite delete.
>> >
>> I haven't looked at e.g. zfs in a long time.
>>
>> A journal-like system which held the deleted/overwritten files
>> or a system of renaming wouldn't be *that* hard to instantiate
>> There are some problems:
>> (a) denial of service by writing and deleting huge [numbers, size]
>> files.
>> (b) retention policy - under what conditions does the system
>>   guarantee existence of backup files?
>> (c) versioning - If I create & delete 'a' six times, how many copies
>> are
>> held.
>> (d) cost of undelete operation - it's not clear how to make
>>      that efficient.
>>
>> I'm sure people can find more.
>>
>> A test version substituting a new open(2) and unlink(2) in libc would
>> be
>> easy to make.
>>
>> geoff steckel
>>
>
> I'm thinking something like a trashcan. Where rm(1) actually just
> moves the files to some predetermined location then on shutdown all
> files older than some configureable date are actually unlinked.
>
> Edgar

you can write a shell script to move given parameters into a special
folder
and make alias rm="that_script"
and a rc script which empty this folder at boot/shutdown.

Reply | Threaded
Open this post in threaded view
|

Re: ffs undelete was: Re: single user question

Edgar Pettijohn III-2
In reply to this post by gwes-2

On May 18, 2019 4:08 AM, Solène Rapenne <[hidden email]> wrote:

>
> Le 2019-05-17 22:47, Edgar Pettijohn a écrit :
> > On May 17, 2019 3:14 PM, gwes <[hidden email]> wrote:
> >>
> >>
> >>
> >> On 5/17/19 2:34 PM, Nathan Hartman wrote:
> >> > On Fri, May 17, 2019 at 12:28 PM ropers <[hidden email]> wrote:
> >> >
> >> >
> >> > In the history of the (Berkeley) Fast File System, has there ever been
> >> > an attempt to implement DOS-like undelete for FFS/UFS?
> >> >
> >> > Maybe that could work for "normal delete" while making available a separate
> >> > "secure delete" that cannot be un-deleted and furthermore overwrites the
> >> > deleted data with random garbage. Administrators could optionally force the
> >> > secure overwrite delete.
> >> >
> >> I haven't looked at e.g. zfs in a long time.
> >>
> >> A journal-like system which held the deleted/overwritten files
> >> or a system of renaming wouldn't be *that* hard to instantiate
> >> There are some problems:
> >> (a) denial of service by writing and deleting huge [numbers, size]
> >> files.
> >> (b) retention policy - under what conditions does the system
> >>   guarantee existence of backup files?
> >> (c) versioning - If I create & delete 'a' six times, how many copies
> >> are
> >> held.
> >> (d) cost of undelete operation - it's not clear how to make
> >>      that efficient.
> >>
> >> I'm sure people can find more.
> >>
> >> A test version substituting a new open(2) and unlink(2) in libc would
> >> be
> >> easy to make.
> >>
> >> geoff steckel
> >>
> >
> > I'm thinking something like a trashcan. Where rm(1) actually just
> > moves the files to some predetermined location then on shutdown all
> > files older than some configureable date are actually unlinked.
> >
> > Edgar
>
> you can write a shell script to move given parameters into a special
> folder
> and make alias rm="that_script"
> and a rc script which empty this folder at boot/shutdown.
>

Im thinking putting the script in ~/bin/rm may be better long term. Either way just shows there isn't a pressing need to make code changes for what a couple lines of shell scripts can do fairly easily.

Edgar

12