how to create a file with copy/read denied to it

[sh.vipin]

Hi,

How can i write a file such that no body can read it or copy it.
I am sure many will ask me to explain why i want to do it. Answer to
which is the analogy, I would like to draw as following.

I have a program "BURNER"
Burner writes another C file "abc.c"

I wan to create abc.c in a /tmp kind of temporary location. Compile it
and have a.out generated and remove abc.c. But at the end I don't want
to leave a trace about how a.out was created. That is abc.c needs to
be deleted at the end.

I want to discuss how can i make sure that in between no body can
1. copy the abc.c
2. do display like "cat abc.c"
3. any other possible threat like wrapper over "rm" command or "gcc"
itself.


thanks
vipin

 

[Beej Jorgensen]

I want to discuss how can i make sure that in between no body can
1. copy the abc.c
2. do display like "cat abc.c"

The part you're interested in the Unix umask() call to set that
process's file creation mask, which is better discussed on
comp.unix.programmer, so I recommend going over there where you'll get
much better answers than you'll get here. (Also "man 2 umask".)

Hint: try calling umask(0077) before fopen().

-Beej

 

[sh.vipin]

The part you're interested in the Unix umask() call to set that
process's file creation mask, which is better discussed on
comp.unix.programmer, so I recommend going over there where you'll get
much better answers than you'll get here.  (Also "man 2 umask".)

Hint: try calling umask(0077) before fopen().

-Beej

Thanks Beej. Thanks Gordon.

 

[James Kuyper]

....
Of what use is a file that nobody can read? ...

Think of /dev/null on a Unix system. As you point out, such a file would
not be the correct solution to his problem, but it has proved a useful
thing to have.

 

[jameskuyper]

On a correctly configured system, you CAN read /dev/null as though
it were an empty file.

But when you try read an empty file, the read fails; nothing is
actually read from it.

 

[jameskuyper]

Gordon Burditt wrote:
....

EOF is not a failure condition for reading data.

if feof(file) is true after trying to read the first character of a
file, then no data was actually read from the file.

 

[Willem]

jameskuyper wrote:
) Gordon Burditt wrote:
) ...
)> >But when you try read an empty file, the read fails; nothing is
)> >actually read from it.
)>
)> EOF is not a failure condition for reading data.
)
) if feof(file) is true after trying to read the first character of a
) file, then no data was actually read from the file.

And if feof(file) is true after trying to read the second character
of a file, then only one character was actually read from the file.

What's the difference ?


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

 

[jameskuyper]

jameskuyper wrote:
) Gordon Burditt wrote:
) ...
)> >But when you try read an empty file, the read fails; nothing is
)> >actually read from it.
)>
)> EOF is not a failure condition for reading data.
)
) if feof(file) is true after trying to read the first character of a
) file, then no data was actually read from the file.

And if feof(file) is true after trying to read the second character
of a file, then only one character was actually read from the file.

What's the difference ?

One character. However, it's that one character which marks the
difference between not reading anything from the file, and reading
something from the file.

 

[Richard Tobin]

You can actually mess things up rather badly
with "chmod 0 /dev/null" run as root, as many things use it.

You can also get amusing results if /dev/null is somehow replaced by a
plain, world-writable file. I have seen this happen by mistake.

-- Richard

 

[Richard Bos]

Think of /dev/null on a Unix system. As you point out, such a file would
not be the correct solution to his problem, but it has proved a useful
thing to have.

But surely you _can_ read /dev/null? You'll get nothing out of it, but
that isn't the same thing.

Richard

 

[James Kuyper]

But surely you _can_ read /dev/null? You'll get nothing out of it, but
that isn't the same thing.

I have to disagree - it is very much the same thing. Is it eating if I
open my mouth but take in no food? Is it typing if I put my hands into
position to type, but hit no keys? Is it running if I get in position to
start a race, but never move? Then how can my program be reading if it
takes in no data from the file?

 

[Chris Dollin]

I have to disagree - it is very much the same thing. Is it eating if I
open my mouth but take in no food? Is it typing if I put my hands into
position to type, but hit no keys? Is it running if I get in position to
start a race, but never move? Then how can my program be reading if it
takes in no data from the file?

It invokes read, which eats/hits/runs as it will; that no bytes
ended up in the buffer doesn't mean read didn't read, it means that
it /did/ read, but got nothing.

You can read /dev/null, but you can't read /dev/spoo. I can read
~kers/.bash_profile, but you can't (even if I gave you an account on
this 'ere machine).

 

[Keith Thompson]

I have to disagree - it is very much the same thing. Is it eating if
I open my mouth but take in no food? Is it typing if I put my hands
into position to type, but hit no keys? Is it running if I get in
position to start a race, but never move? Then how can my program be
reading if it takes in no data from the file?

It's like the difference between "" and (char*)NULL. It's like the
difference between what you see with your eyes closed and what you see
with your ears.

When I try to read a byte from /dev/null, feof() becomes true, but
ferror() does not.

If I executed "sudo chmod a-r /dev/null" on my system, bad things
could happen. There's a very real difference between an empty but
readable file and a non-readable file, and IMHO it's more significant
than the difference between a readable file that happens to be 0 bytes
long and a readable file that happens to be 1 byte long.

 

[jameskuyper]

James Kuyper wrote: ....

It invokes read, which eats/hits/runs as it will; that no bytes
ended up in the buffer doesn't mean read didn't read, it means that
it /did/ read, but got nothing.

By the same logic, if I open a wrapper that's supposed to contain a
hamburger, and there's no hamburger there, I've still "eaten" a
hamburger? Do you know what part of the world uses English in this
fashion? I'm thinking of opening a hyper-fast "food" restaurant there
to take advantage of this concept. In this area, I could get sued if I
tried to do something like that.

 

[jameskuyper]

It's like the difference between "" and (char*)NULL.

I agree that there is a difference. *"" has a value of 0, while *
(char*)NULL has undefined behavior. However, I wouldn't describe
either expression as "retrieving a character from a string".

Similarly, I surely recognize the difference between being unable to
open a file because my program doesn't have the required permissions,
or it doesn't exist, and being unable to read a file that was
successfully opened because the file was empty. However, I wouldn't
describe either sequence of events by saying that the program read the
file.

... It's like the
difference between what you see with your eyes closed and what you see
with your ears.

I think you were intending that analogy to be understood with the
eyelids approximated as 100% opaque. Otherwise, it doesn't quiet hold
up.

....

When I try to read a byte from /dev/null, feof() becomes true, but
ferror() does not.

Which means that there was nothing read, but no error occurred.

If I executed "sudo chmod a-r /dev/null" on my system, bad things
could happen. There's a very real difference between an empty but
readable file and a non-readable file, and IMHO it's more significant
than the difference between a readable file that happens to be 0 bytes
long and a readable file that happens to be 1 byte long.

True, but it's only possible to actually read from the last file you
described. The empty file is "readable" only in the sense that you can
attempt to read it without producing an error indication; it can't
actually be read, because there is nothing to read.

 

[Nate Eldredge]

By the same logic, if I open a wrapper that's supposed to contain a
hamburger, and there's no hamburger there, I've still "eaten" a
hamburger? Do you know what part of the world uses English in this
fashion? I'm thinking of opening a hyper-fast "food" restaurant there
to take advantage of this concept. In this area, I could get sued if I
tried to do something like that.

In mathematics, it's very common for definitions to include "trivial"
cases. The idea of a set is "something that contains elements", but a
set which contains no elements (the empty set) is still a set, and a
very important one. A function whose domain is the empty set is a
continuous function (it is continuous at every point of its domain,
since there are no such points). The statements "If pigs have wings,
then I am the king of Siam" and "All white crows are blue" are both
true.

In your example, if your wrapper was to contain "a" hamburger, i.e. one,
you could say that it is a hamburger of zero size, if you did not
otherwise specify a minimum size. Alternatively, if you said the
wrapper contained "hamburger", without specifying how much, "none" would
be a legitimate amount.

Granted, this is not the way ordinary people talk, and therefore they
(and the law) would probably consider your restaurant deceptive. But it
is the way mathematicians and others concerned with precise logic talk,
and IMHO is not inappropriate in a field like computer science, which
certainly is concerned with precise logic.

I'll also point out that in the case of reading a file, it is normal to
consider "end-of-file" as a successful read of zero bytes, not an error.
Granted, it is one that generally has to be handled differently than a
successful read of a positive number of bytes. But for instance, on
Unix it does not set `errno'. A program that printed an error message
whenever end-of-file was reached would be quite obnoxious to use.

 

[Chris Dollin]

By the same logic, if I open a wrapper that's supposed to contain a
hamburger, and there's no hamburger there, I've still "eaten" a
hamburger?

Opening is not eating. Do you normally use the term "eating" to
include food acquisition and preparation?

As I see it, your own reasoning would suggest that your description of
your activity as "opening" (which is something you do to get at what's
(supposed to be) inside) is incorrect, since there was nothing there.

Do you know what part of the world uses English in this
fashion?
Yes.

I'm thinking of opening a hyper-fast "food" restaurant there
to take advantage of this concept. In this area, I could get sued if I
tried to do something like that.

If the wrapper is contractually obliged to have a hamburger in it,
then sure. Files and streams aren't contractually obliged to have
bytes in them.

I also admit the existence of sets with no elements, the sum of
all the elements of the empty sequence, and the number zero,
and think it makes perfect sense to say that the number of
helicopters in my attic is that same number, which is also the
number of sheep in the car park outside and the number of bytes
I read from /dev/null.

 

[Richard Tobin]

By the same logic, if I open a wrapper that's supposed to contain a
hamburger, and there's no hamburger there, I've still "eaten" a
hamburger?

No, but you have eaten all the hamburgers.

-- Richard

 

[James Kuyper]

jameskuyper wrote: ....

Opening is not eating. Do you normally use the term "eating" to
include food acquisition and preparation?

As I see it, your own reasoning would suggest that your description of
your activity as "opening" (which is something you do to get at what's
(supposed to be) inside) is incorrect, since there was nothing there.

OK - let me modify the analog, by adding an attempt on my part to
actually eat the non-existent hamburger.. The equivalent of fopen() will
be when I unwrap the supposed "hamburger". The equivalent of the fgetc()
call is when I attempt to eat the "hamburger", and the equivalent of the
EOF return value is when my mouth tells me it didn't find any hambuger
left to eat.

 

[Chris Dollin]

OK - let me modify the analog, by adding an attempt on my part to
actually eat the non-existent hamburger.. The equivalent of fopen() will
be when I unwrap the supposed "hamburger". The equivalent of the fgetc()
call is when I attempt to eat the "hamburger", and the equivalent of the
EOF return value is when my mouth tells me it didn't find any hambuger
left to eat.

Here, you're trying to eat a byte when there's no byte there. I agree
that you didn't eat a hamburger. You have, however, eaten all the
hamburgers in the wrapper (since there are no uneaten hamburgers remaining);
and if you read() from /dev/null and do something with every (possibly
none) bite obtained, you are indeed reading.

That's my formalist take on it, anyway.

I think I've used up my OT allocation for this month now.

--
Of /course/ it was deliberate.

"You keep using that word." Inigo, /The Princess Bride/

Hewlett-Packard Limited Cain Road, Bracknell, registered no:
registered office: Berks RG12 1HN 690597 England