Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
fopen() of a read-only file for writing?
1,543 views
Skip to first unread message
Joe Shead
Apr 16, 2012, 7:03:13 PM4/16/12
to
Hi,
I have a file that has no write permissions on it, called readonly.txt. I am logged on as root.
ls -l returns the line:
-r-xr--r-- 1 root root 32 Apr 15 20:20 readonly.txt
I do:
<CODE>
int errnos[4];
FILE *f=0;
errno=0;
errnos[0]=errno;
f=fopen("readonly.txt", "wb");
errnos[1]=errno;
if (f!=0){
putc('a', f);
errnos[2]=errno;
fclose(f); f=0;
errnos[3]=errno;}
</CODE>
I get a non-zero f from fopen(), the putc() works, and all 4 errnos are 0. After executing this code, the file is 1 byte long with just the 'a' in it.
Is this behavior correct?
I'm really not sure, but if someone could explain it to me, or direct me to the right people to talk to, that would help. It seems like fopen() ought to return 0, and set errno to EACCES.
I built my version of linux using lfs (linux from scratch). I'm using linux kernel version 2.4.21, gcc version 3.2.1, and libc version 2.3.1.
Thanks in advance,
Joe
I have a file that has no write permissions on it, called readonly.txt. I am logged on as root.
ls -l returns the line:
-r-xr--r-- 1 root root 32 Apr 15 20:20 readonly.txt
I do:
<CODE>
int errnos[4];
FILE *f=0;
errno=0;
errnos[0]=errno;
f=fopen("readonly.txt", "wb");
errnos[1]=errno;
if (f!=0){
putc('a', f);
errnos[2]=errno;
fclose(f); f=0;
errnos[3]=errno;}
</CODE>
I get a non-zero f from fopen(), the putc() works, and all 4 errnos are 0. After executing this code, the file is 1 byte long with just the 'a' in it.
Is this behavior correct?
I'm really not sure, but if someone could explain it to me, or direct me to the right people to talk to, that would help. It seems like fopen() ought to return 0, and set errno to EACCES.
I built my version of linux using lfs (linux from scratch). I'm using linux kernel version 2.4.21, gcc version 3.2.1, and libc version 2.3.1.
Thanks in advance,
Joe
Alan Curry
Apr 17, 2012, 1:12:31 AM4/17/12
to
In article <s5KdnY85luiJChHS...@earthlink.com>,
Execute permission does matter though. I suspect that's a holdover from the
time when it was common for $PATH to contain "." so there was more potential
to accidentally execute things.
--
Alan Curry
Joe Shead <J...@SheadProgramming.com> wrote:
>
>Hi,
>
>I have a file that has no write permissions on it, called readonly.txt.
>I am logged on as root.
Read and write permissions mean nothing to root.
>
>Hi,
>
>I have a file that has no write permissions on it, called readonly.txt.
>I am logged on as root.
Execute permission does matter though. I suspect that's a holdover from the
time when it was common for $PATH to contain "." so there was more potential
to accidentally execute things.
--
Alan Curry
Joe Shead
Apr 17, 2012, 3:36:28 AM4/17/12
to
Ok, thanks.
I'll test that soon, with a less powerful user, but it's too late right now.
Joseph Shead
"Alan Curry" <pac...@kosh.dhis.org> wrote in message
news:jmiu3v$is7$1...@speranza.aioe.org...
I'll test that soon, with a less powerful user, but it's too late right now.
Joseph Shead
"Alan Curry" <pac...@kosh.dhis.org> wrote in message
news:jmiu3v$is7$1...@speranza.aioe.org...
Joe Shead
Apr 19, 2012, 12:40:32 AM4/19/12
to
I tested it, and it works. With a new non-root user, I got the EACCES that I
expected.
I'll just say, for anyone out there who wants to read my humble opinion,
that sometimes root wants to set things (like relatively stable C++ code, or
an initialization script) to read-only, so he knows that if he opens those
files to take a look, he can't easily accidentally modify them. If he wants
to change the file, he would actually like to be forced to do a chmod, make
the deliberate changes, and then chmod it back to read-only. I do that all
the time.
Thanks for the informed and comprehending help, though,
Joe
expected.
I'll just say, for anyone out there who wants to read my humble opinion,
that sometimes root wants to set things (like relatively stable C++ code, or
an initialization script) to read-only, so he knows that if he opens those
files to take a look, he can't easily accidentally modify them. If he wants
to change the file, he would actually like to be forced to do a chmod, make
the deliberate changes, and then chmod it back to read-only. I do that all
the time.
Thanks for the informed and comprehending help, though,
Joe
Richard Kettlewell
Apr 19, 2012, 3:57:01 AM4/19/12
to
"Joe Shead" <J...@SheadProgramming.com> writes:
> I tested it, and it works. With a new non-root user, I got the EACCES
> that I expected.
>
> I'll just say, for anyone out there who wants to read my humble
> opinion, that sometimes root wants to set things (like relatively
> stable C++ code, or an initialization script) to read-only, so he
> knows that if he opens those files to take a look, he can't easily
> accidentally modify them. If he wants to change the file, he would
> actually like to be forced to do a chmod, make the deliberate changes,
> and then chmod it back to read-only. I do that all the time.
root has a several options, given those requirements: become some other
> I tested it, and it works. With a new non-root user, I got the EACCES
> that I expected.
>
> I'll just say, for anyone out there who wants to read my humble
> opinion, that sometimes root wants to set things (like relatively
> stable C++ code, or an initialization script) to read-only, so he
> knows that if he opens those files to take a look, he can't easily
> accidentally modify them. If he wants to change the file, he would
> actually like to be forced to do a chmod, make the deliberate changes,
> and then chmod it back to read-only. I do that all the time.
UID; surrender CAP_DAC_OVERRIDE (and perhaps some other capabilities);
don't become root (or otherwise acquire powerful capabilities) in the
first place.
--
http://www.greenend.org.uk/rjk/
Rainer Weikusat
Apr 19, 2012, 9:18:33 AM4/19/12
to
"Joe Shead" <J...@SheadProgramming.com> writes:
> I tested it, and it works. With a new non-root user, I got the EACCES that I
> expected.
>
> I'll just say, for anyone out there who wants to read my humble opinion,
> that sometimes root wants to set things (like relatively stable C++ code, or
> an initialization script) to read-only, so he knows that if he opens those
> files to take a look, he can't easily accidentally modify them. If he wants
> to change the file, he would actually like to be forced to do a chmod, make
> the deliberate changes, and then chmod it back to read-only. I do that all
> the time.
The most reliable solution would 'ensure that you have up-to-date
> I tested it, and it works. With a new non-root user, I got the EACCES that I
> expected.
>
> I'll just say, for anyone out there who wants to read my humble opinion,
> that sometimes root wants to set things (like relatively stable C++ code, or
> an initialization script) to read-only, so he knows that if he opens those
> files to take a look, he can't easily accidentally modify them. If he wants
> to change the file, he would actually like to be forced to do a chmod, make
> the deliberate changes, and then chmod it back to read-only. I do that all
> the time.
backups'. Apart from that, if on ext?, you might want to have a look
at chattr(1), specifically, the 'i' ('immutable') attribute.
Grant Edwards
Apr 19, 2012, 10:16:39 AM4/19/12
to
On 2012-04-19, Joe Shead <J...@SheadProgramming.com> wrote:
> I tested it, and it works. With a new non-root user, I got the EACCES that I
> expected.
>
> I'll just say, for anyone out there who wants to read my humble opinion,
> that sometimes root wants to set things (like relatively stable C++ code, or
> an initialization script) to read-only, so he knows that if he opens those
> files to take a look,
Don't do stuff like that (browsing around looking at source code) as
> I tested it, and it works. With a new non-root user, I got the EACCES that I
> expected.
>
> I'll just say, for anyone out there who wants to read my humble opinion,
> that sometimes root wants to set things (like relatively stable C++ code, or
> an initialization script) to read-only, so he knows that if he opens those
> files to take a look,
root.
> he can't easily accidentally modify them. If he wants to change the
> file, he would actually like to be forced to do a chmod, make the
> deliberate changes, and then chmod it back to read-only. I do that
> all the time.
Browse around as a normal user and then use sudo when you decide you
want to change something that requires root privleges.
--
Grant Edwards grant.b.edwards Yow! You should all JUMP
at UP AND DOWN for TWO HOURS
gmail.com while I decide on a NEW
CAREER!!
Joe Shead
Apr 20, 2012, 9:10:26 PM4/20/12
to
Hi everyone,
The file system I'm working with has been a problem. The machine is
multi-boot. I've been working on a C++ utility class library, that compiles
in two programming environments in MS Windows (Borland C++Builder 6, and
Visual Studio 2003), and in linux, and I've written an extensive test
program for it. Things have to pass in all three environments, which is
where the fopen() thing came up (which I consider solved, now, in several
ways).
So, the library resides on a FAT file system. The FAT file system has space
in the directory for only one set of permission attributes, and I don't
think there is any 'owner' of the file. So, when I mount that partition,
linux has to interpret the FAT directory information in terms of linux file
system idioms. It assigns an owner and a group to each file, and so what's
it going to be, but root and root? And there's the rub, which I worked on
yesterday into the wee hours.
So, the way that I initially got a test using a user other than root, 'joe',
was to do a make on the linux tester project for my utilities, logged on as
root in one virtual console, and have root copy the executable file,
'sptest', over to the home directory for 'joe', and have root do a chown()
to 'joe' on that file, and I tried out various settings with chmod(). I then
ran it in a different virtual console, logged in as joe, which worked as
expected. When joe sets his own w bit (u-w) to off, then joe can't open his
own file.
Now, that's basically what I did to test what Alan told me.
Rainer's points-----------
I then tested Rainer's 'immutable' point. The file system for most of my
linux setup is ext3. Setting the immutable bit with chattr() worked simply.
Even root can't open that file for writing.
I've got it all backed up. There's no point in proceding if you don't back
up your stuff. But, when programming, you still want to know that your
stable utilities are the same as they are in your archived 'freeze' file.
When I am done working on a version of the utilities, I zip them up in a
file with a name like: spUtils01.01.02_20070820_int.zip. That's my last
freeze, with version number and date in the file name, and in a form that
will have them automatically order correctly alphanumerically. While working
on it, daily backups are done in other ways. It's really nice to have each
stable version boxed up in that zip, though.
Richard's and Grant's points------------
I couldn't find CAP_DAC_OVERRIDE in my info system, so I went on to other
things.
Regarding rooting, I've got a bad habit of logging on as root in linux, and
as Administrator in ms windows. Life is easier that way, but I agree that it
has its pitfalls. I'm not too worried about deleting dll's in System32, or
system commands in linux, but I imagine that the probability of a hacker or
malware getting going with elevated privileges is probably higher if you're
logged on as the most powerful user. It's just that, as a programmer, I'm
often times trying to figure out what's wrong with something, and I don't
like the idea of things being hidden from view. Also, in the mid to late
'90's, I became very distrustful of Windows and installation programs.
Second, I discovered that in some ways I was limited to being only one user.
When I create a user in Windows, and log on as that user, I discover that
none of my installed software is available. It was installed under
Administrator. So, there were entanglements.
So, anyway, in linux, as of now, I'm trying to function as a normal user as
much as possible, to take your advice, and because I think it's probably
better for security (don't roll your eyes). What I did was to make two bash
scripts, that I run when I'm entering linux after working in windows, and
another to run before rebooting and going over to windows. One copies the
utilities and linux-related parts of the spUtils directory tree using about
a half-dozen cp commands from the FAT file system into a tree under joe's
ext3 home directory, and the other takes them back. It took probably about
six hours to get those straight, and I have previous experience with bash
scripts. I use the -u and --preserve=timestamp options, which seems to do
the trick. I can't see the commands, so I hope I've got that --preserve
option spelled right. It apparently means to transfer the timestamp from the
source file to the destination file.
I run the two scripts logged on as root, because they access the mounted FAT
file-system. Then, I can logout as root and logon as joe, or do an su. I
don't have sudo on my installation, but it looks like I could use that to
run the two scripts, and never directly logon as root. I just took a look at
https://www.linux.com/learn/tutorials/306766-linux-101-introduction-to-sudo.
Also, for anybody reading this, I should mention that, regarding the
original problem, what Alan said is explained very well in info, under the
section "File System Interface."
Anyway, thanks again for your help and advice,
Joseph Shead
President
Shead Programming
The file system I'm working with has been a problem. The machine is
multi-boot. I've been working on a C++ utility class library, that compiles
in two programming environments in MS Windows (Borland C++Builder 6, and
Visual Studio 2003), and in linux, and I've written an extensive test
program for it. Things have to pass in all three environments, which is
where the fopen() thing came up (which I consider solved, now, in several
ways).
So, the library resides on a FAT file system. The FAT file system has space
in the directory for only one set of permission attributes, and I don't
think there is any 'owner' of the file. So, when I mount that partition,
linux has to interpret the FAT directory information in terms of linux file
system idioms. It assigns an owner and a group to each file, and so what's
it going to be, but root and root? And there's the rub, which I worked on
yesterday into the wee hours.
So, the way that I initially got a test using a user other than root, 'joe',
was to do a make on the linux tester project for my utilities, logged on as
root in one virtual console, and have root copy the executable file,
'sptest', over to the home directory for 'joe', and have root do a chown()
to 'joe' on that file, and I tried out various settings with chmod(). I then
ran it in a different virtual console, logged in as joe, which worked as
expected. When joe sets his own w bit (u-w) to off, then joe can't open his
own file.
Now, that's basically what I did to test what Alan told me.
Rainer's points-----------
I then tested Rainer's 'immutable' point. The file system for most of my
linux setup is ext3. Setting the immutable bit with chattr() worked simply.
Even root can't open that file for writing.
I've got it all backed up. There's no point in proceding if you don't back
up your stuff. But, when programming, you still want to know that your
stable utilities are the same as they are in your archived 'freeze' file.
When I am done working on a version of the utilities, I zip them up in a
file with a name like: spUtils01.01.02_20070820_int.zip. That's my last
freeze, with version number and date in the file name, and in a form that
will have them automatically order correctly alphanumerically. While working
on it, daily backups are done in other ways. It's really nice to have each
stable version boxed up in that zip, though.
Richard's and Grant's points------------
I couldn't find CAP_DAC_OVERRIDE in my info system, so I went on to other
things.
Regarding rooting, I've got a bad habit of logging on as root in linux, and
as Administrator in ms windows. Life is easier that way, but I agree that it
has its pitfalls. I'm not too worried about deleting dll's in System32, or
system commands in linux, but I imagine that the probability of a hacker or
malware getting going with elevated privileges is probably higher if you're
logged on as the most powerful user. It's just that, as a programmer, I'm
often times trying to figure out what's wrong with something, and I don't
like the idea of things being hidden from view. Also, in the mid to late
'90's, I became very distrustful of Windows and installation programs.
Second, I discovered that in some ways I was limited to being only one user.
When I create a user in Windows, and log on as that user, I discover that
none of my installed software is available. It was installed under
Administrator. So, there were entanglements.
So, anyway, in linux, as of now, I'm trying to function as a normal user as
much as possible, to take your advice, and because I think it's probably
better for security (don't roll your eyes). What I did was to make two bash
scripts, that I run when I'm entering linux after working in windows, and
another to run before rebooting and going over to windows. One copies the
utilities and linux-related parts of the spUtils directory tree using about
a half-dozen cp commands from the FAT file system into a tree under joe's
ext3 home directory, and the other takes them back. It took probably about
six hours to get those straight, and I have previous experience with bash
scripts. I use the -u and --preserve=timestamp options, which seems to do
the trick. I can't see the commands, so I hope I've got that --preserve
option spelled right. It apparently means to transfer the timestamp from the
source file to the destination file.
I run the two scripts logged on as root, because they access the mounted FAT
file-system. Then, I can logout as root and logon as joe, or do an su. I
don't have sudo on my installation, but it looks like I could use that to
run the two scripts, and never directly logon as root. I just took a look at
https://www.linux.com/learn/tutorials/306766-linux-101-introduction-to-sudo.
Also, for anybody reading this, I should mention that, regarding the
original problem, what Alan said is explained very well in info, under the
section "File System Interface."
Anyway, thanks again for your help and advice,
Joseph Shead
President
Shead Programming
Richard Kettlewell
Apr 21, 2012, 5:20:46 AM4/21/12
to
"Joe Shead" <J...@SheadProgramming.com> writes:
> So, the library resides on a FAT file system. The FAT file system has space
> in the directory for only one set of permission attributes, and I don't
> think there is any 'owner' of the file. So, when I mount that partition,
> linux has to interpret the FAT directory information in terms of linux file
> system idioms. It assigns an owner and a group to each file, and so what's
> it going to be, but root and root?
You get to choose. See 'man mount' for details.
> So, the library resides on a FAT file system. The FAT file system has space
> in the directory for only one set of permission attributes, and I don't
> think there is any 'owner' of the file. So, when I mount that partition,
> linux has to interpret the FAT directory information in terms of linux file
> system idioms. It assigns an owner and a group to each file, and so what's
> it going to be, but root and root?
> I've got it all backed up. There's no point in proceding if you don't back
> up your stuff. But, when programming, you still want to know that your
> stable utilities are the same as they are in your archived 'freeze' file.
> When I am done working on a version of the utilities, I zip them up in a
> file with a name like: spUtils01.01.02_20070820_int.zip. That's my last
> freeze, with version number and date in the file name, and in a form that
> will have them automatically order correctly alphanumerically. While working
> on it, daily backups are done in other ways. It's really nice to have each
> stable version boxed up in that zip, though.
> Richard's and Grant's points------------
> I couldn't find CAP_DAC_OVERRIDE in my info system, so I went on to other
> things.
--
http://www.greenend.org.uk/rjk/
Joe Shead
Apr 22, 2012, 2:07:44 AM4/22/12
to
Ok, thanks Richard. I'll work on some of that.
"Richard Kettlewell" <r...@greenend.org.uk> wrote in message
news:8762ctl...@araminta.anjou.terraraq.org.uk...
"Richard Kettlewell" <r...@greenend.org.uk> wrote in message
news:8762ctl...@araminta.anjou.terraraq.org.uk...
Joe Shead
Apr 23, 2012, 5:24:28 PM4/23/12
to
Ok,
I changed the mount parameters in fstab from 'defaults' (hey, it was 2003)
to:
mount -t vfat -o user,exec,suid,rw,uid=1054,gid=269,shortname=mixed
/dev/hda8 /data
That worked wonders, the user and uid parts being key. I haven't checked
whether suid was necessary. Now, I can work directly on the data again, as a
normal user.
-----
I found CAP_DAC_OVERRIDE -- definitely don't want to go there.
Joe
"Richard Kettlewell" <r...@greenend.org.uk> wrote in message
news:8762ctl...@araminta.anjou.terraraq.org.uk...
I changed the mount parameters in fstab from 'defaults' (hey, it was 2003)
to:
mount -t vfat -o user,exec,suid,rw,uid=1054,gid=269,shortname=mixed
/dev/hda8 /data
That worked wonders, the user and uid parts being key. I haven't checked
whether suid was necessary. Now, I can work directly on the data again, as a
normal user.
-----
I found CAP_DAC_OVERRIDE -- definitely don't want to go there.
Joe
"Richard Kettlewell" <r...@greenend.org.uk> wrote in message
news:8762ctl...@araminta.anjou.terraraq.org.uk...
0 new messages