Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.development.apps > #458 > unrolled thread

fopen() of a read-only file for writing?

Back to article view | Back to comp.os.linux.development.apps

Contents

  fopen() of a read-only file for writing? "Joe Shead" <Joe@SheadProgramming.com> - 2012-04-16 17:03 -0600
    Re: fopen() of a read-only file for writing? pacman@kosh.dhis.org (Alan Curry) - 2012-04-17 05:12 +0000
      Re: fopen() of a read-only file for writing? "Joe Shead" <Joe@SheadProgramming.com> - 2012-04-17 01:36 -0600
      Re: fopen() of a read-only file for writing? "Joe Shead" <Joe@SheadProgramming.com> - 2012-04-18 22:40 -0600
        Re: fopen() of a read-only file for writing? Richard Kettlewell <rjk@greenend.org.uk> - 2012-04-19 08:57 +0100
        Re: fopen() of a read-only file for writing? Rainer Weikusat <rweikusat@mssgmbh.com> - 2012-04-19 14:18 +0100
        Re: fopen() of a read-only file for writing? Grant Edwards <invalid@invalid.invalid> - 2012-04-19 14:16 +0000
        Re: fopen() of a read-only file for writing? "Joe Shead" <Joe@SheadProgramming.com> - 2012-04-20 19:10 -0600
          Re: fopen() of a read-only file for writing? Richard Kettlewell <rjk@greenend.org.uk> - 2012-04-21 10:20 +0100
            Re: fopen() of a read-only file for writing? "Joe Shead" <Joe@SheadProgramming.com> - 2012-04-22 00:07 -0600
            Re: fopen() of a read-only file for writing? "Joe Shead" <Joe@SheadProgramming.com> - 2012-04-23 15:24 -0600

#458 — fopen() of a read-only file for writing?

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [next] | [standalone]

#459

In article <s5KdnY85luiJChHSnZ2dnUVZ_uGdnZ2d@earthlink.com>,
Joe Shead <Joe@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.

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

[toc] | [prev] | [next] | [standalone]

#460

Ok, thanks.

I'll test that soon, with a less powerful user, but it's too late right now.

Joseph Shead

"Alan Curry" <pacman@kosh.dhis.org> wrote in message
news:jmiu3v$is7$1@speranza.aioe.org...
> In article <s5KdnY85luiJChHSnZ2dnUVZ_uGdnZ2d@earthlink.com>,
> Joe Shead <Joe@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.
>
> 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

[toc] | [prev] | [next] | [standalone]

#462

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

"Alan Curry" <pacman@kosh.dhis.org> wrote in message
news:jmiu3v$is7$1@speranza.aioe.org...
> In article <s5KdnY85luiJChHSnZ2dnUVZ_uGdnZ2d@earthlink.com>,
> Joe Shead <Joe@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.
>
> 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

[toc] | [prev] | [next] | [standalone]

#464

"Joe Shead" <Joe@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
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/

[toc] | [prev] | [next] | [standalone]

#465

"Joe Shead" <Joe@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
backups'. Apart from that, if on ext?, you might want to have a look
at chattr(1), specifically, the 'i' ('immutable') attribute.

[toc] | [prev] | [next] | [standalone]

#466

On 2012-04-19, Joe Shead <Joe@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
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.

Don't log in as root.

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!!

[toc] | [prev] | [next] | [standalone]

#467

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

[toc] | [prev] | [next] | [standalone]

#468

"Joe Shead" <Joe@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.

> 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.

It sounds like you might benefit form a version control system.

> Richard's and Grant's points------------
> I couldn't find CAP_DAC_OVERRIDE in my info system, so I went on to other
> things.

Start from 'man capabilities'.

-- 
http://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#469

Ok, thanks Richard. I'll work on some of that.

"Richard Kettlewell" <rjk@greenend.org.uk> wrote in message
news:8762ctl9u9.fsf@araminta.anjou.terraraq.org.uk...
> "Joe Shead" <Joe@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.
>
> > 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.
>
> It sounds like you might benefit form a version control system.
>
> > Richard's and Grant's points------------
> > I couldn't find CAP_DAC_OVERRIDE in my info system, so I went on to
other
> > things.
>
> Start from 'man capabilities'.
>
> -- 
> http://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#470

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" <rjk@greenend.org.uk> wrote in message
news:8762ctl9u9.fsf@araminta.anjou.terraraq.org.uk...
> "Joe Shead" <Joe@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.
>
> > 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.
>
> It sounds like you might benefit form a version control system.
>
> > Richard's and Grant's points------------
> > I couldn't find CAP_DAC_OVERRIDE in my info system, so I went on to
other
> > things.
>
> Start from 'man capabilities'.
>
> -- 
> http://www.greenend.org.uk/rjk/

[toc] | [prev] | [standalone]

Back to top | Article view | comp.os.linux.development.apps

csiph-web