files

ashu · External Since: Jul 05, 2007 Posts: 4

i want to make a program that accept a file and chechs if it is
readable and writable and give appropriate messeage ?
i can make program to accpet filename from command line and open it
in any omde and write data in it, but to know its permission is
seems tricky, is there apecific function available ?

ashu · External Since: Jul 05, 2007 Posts: 4

On Jul 20, 5:02 pm, Nick Leverton <n... DeleteThis @leverton.org> wrote:
> In article <1184931435.842216.219... DeleteThis @x40g2000prg.googlegroups.com>,
>
> ashu <ashishmoury... DeleteThis @gmail.com> wrote:
> >i want to make a program that accept a file and chechs if it is
> > readable and writable and give appropriate messeage ?
> > i can make program to accpet filename from command line and open it
> > in any omde and write data in it, but to know its permission is
> > seems tricky, is there apecific function available ?
>
> stat() if you have a filename
> fstat() if you have a filehandle
> lstat() is special for getting at symbolic links - but normally you
> don't need to worry about it.
>
> Nick
> --http://www.leverton.org/blosxom ... So express yourself

thankx can u give a example , how to use it?

Nick Leverton · External Since: Dec 24, 2004 Posts: 54

In article <1184931435.842216.219440.DeleteThis@x40g2000prg.googlegroups.com>,
ashu <ashishmourya21.DeleteThis@gmail.com> wrote:
>i want to make a program that accept a file and chechs if it is
> readable and writable and give appropriate messeage ?
> i can make program to accpet filename from command line and open it
> in any omde and write data in it, but to know its permission is
> seems tricky, is there apecific function available ?

stat() if you have a filename
fstat() if you have a filehandle
lstat() is special for getting at symbolic links - but normally you
don't need to worry about it.

Nick
--
http://www.leverton.org/blosxom ... So express yourself

ashu · External Since: Jul 05, 2007 Posts: 4

On Jul 21, 12:00 am, Nix <nix-razor-... RemoveThis @esperi.org.uk> wrote:
> On 20 Jul 2007, ashu verbalised:
>
> > i want to make a program that accept a file and chechs if it is
> > readable and writable and give appropriate messeage ?
> > i can make program to accpet filename from command line and open it
> > in any omde and write data in it, but to know its permission is
> > seems tricky, is there apecific function available ?
>
> The only sane way to tell if you right now have permissions to open a
> file is to use open(). Checking the permission bits to do this is silly.
>
> This does indeed smell like a homework assignment.
>
> (hm, I should have suggested unlink(), *snicker*)
>
> --
> `... in the sense that dragons logically follow evolution so they would
> be able to wield metal.' --- Kenneth Eng's colourless green ideas sleep
> furiously

actually it is not homework it is from old question paper and i m
trying to make it in C

Ian Rawlings · External Since: Oct 07, 2006 Posts: 238

On 2007-07-20, ashu <ashishmourya21.TakeThisOut@gmail.com> wrote:

>> stat() if you have a filename
>> fstat() if you have a filehandle
>> lstat() is special for getting at symbolic links - but normally you
>> don't need to worry about it.
>
> thankx can u give a example , how to use it?

"man 2 stat" etc..

--
Blast off and strike the evil Bydo empire!

Tim Southerwood · External Since: Apr 23, 2007 Posts: 113

ashu wrote:

> On Jul 20, 5:02 pm, Nick Leverton <n... RemoveThis @leverton.org> wrote:
>> In article <1184931435.842216.219... RemoveThis @x40g2000prg.googlegroups.com>,
>>
>> ashu <ashishmoury... RemoveThis @gmail.com> wrote:
>> >i want to make a program that accept a file and chechs if it is
>> > readable and writable and give appropriate messeage ?
>> > i can make program to accpet filename from command line and open it
>> > in any omde and write data in it, but to know its permission is
>> > seems tricky, is there apecific function available ?
>>
>> stat() if you have a filename
>> fstat() if you have a filehandle
>> lstat() is special for getting at symbolic links - but normally you
>> don't need to worry about it.
>>
>> Nick
>> --http://www.leverton.org/blosxom ... So express
>> yourself
>
> thankx can u give a example , how to use it?

Well, you can save yourself a lot of trouble by doing it in perl:

[untested]

#!/usr/bin/perl
use strict;
use warnings;

my $file = shift; # Get arg1 from command line

die "Must give me a filename" unless defined $file;

die "File [$file] is not readable" unless -r $file;
die "File [$file] is not writeable" unless -w $file;

#### End

As for stat etc:

man -S2 stat

will give you the details. Bear in mind that both stat and the perl example
might get thwarted by ACLs or the filesystem being RO mounted or many other
weird cases, so the next easiest way is to simply attempt to open the file
in read or read-write mode and see if it allows you to or fails.

man -S2 open

Cheers

Tim

Chris Davies · External Since: Apr 13, 2004 Posts: 267

ashu <ashishmourya21.DeleteThis@gmail.com> wrote:
> i want to make a program that accept a file and chechs if it is
> readable and writable and give appropriate messeage ?

What programming language do you want to use? Shell script? Perl? C?
Something else?

Chris

Tony van der Hoff · External Since: Oct 15, 2005 Posts: 74

On 20 Jul at 12:37 ashu <ashishmourya21 DeleteThis @gmail.com> wrote in message
<1184931435.842216.219440 DeleteThis @x40g2000prg.googlegroups.com>

> i want to make a program that accept a file and chechs if it is
> readable and writable and give appropriate messeage ?
> i can make program to accpet filename from command line and open it
> in any omde and write data in it, but to know its permission is
> seems tricky, is there apecific function available ?
>

Looks like a homework assignment to me. Read your lecture notes.

--
Tony van der Hoff | mailto:tony@vanderhoff.org
Buckinghamshire, England

Nick Leverton · External Since: Dec 24, 2004 Posts: 54

In article <1184933653.679921.198910.TakeThisOut@i13g2000prf.googlegroups.com>,
ashu <ashishmourya21.TakeThisOut@gmail.com> wrote:
>On Jul 20, 5:02 pm, Nick Leverton <n....TakeThisOut@leverton.org> wrote:
>
>> stat() if you have a filename
>> fstat() if you have a filehandle
>> lstat() is special for getting at symbolic links - but normally you
>> don't need to worry about it.
>
>thankx can u give a example , how to use it?

Man pages normally have good usage examples in. Do "man 2 stat" at a
command prompt. In this case it helps to specify section 2, as many
distros also include a stat in section 1 (user programs).

Nick
--
http://www.leverton.org/blosxom ... So express yourself

Nix · External Since: Jul 29, 2004 Posts: 680

On 20 Jul 2007, ashu verbalised:

> i want to make a program that accept a file and chechs if it is
> readable and writable and give appropriate messeage ?
> i can make program to accpet filename from command line and open it
> in any omde and write data in it, but to know its permission is
> seems tricky, is there apecific function available ?

The only sane way to tell if you right now have permissions to open a
file is to use open(). Checking the permission bits to do this is silly.

This does indeed smell like a homework assignment.

(hm, I should have suggested unlink(), *snicker*)

--
`... in the sense that dragons logically follow evolution so they would
be able to wield metal.' --- Kenneth Eng's colourless green ideas sleep
furiously

Bruce Stephens · External Since: Aug 19, 2004 Posts: 179

ashu <ashishmourya21.RemoveThis@gmail.com> writes:

[...]

> actually it is not homework it is from old question paper and i m
> trying to make it in C

Unlikely time of the year for homework, I guess.

But Nix's point stands in that you're creating a race condition if
you're trying to do anything with the file based on the permissions.

Nick Leverton · External Since: Dec 24, 2004 Posts: 54

In article <87d4ymkhsd.fsf.TakeThisOut@cenderis.demon.co.uk>,
Bruce Stephens <bruce+usenet@cenderis.demon.co.uk> wrote:
>ashu <ashishmourya21.TakeThisOut@gmail.com> writes:
>
>[...]
>
>> actually it is not homework it is from old question paper and i m
>> trying to make it in C
>
>Unlikely time of the year for homework, I guess.
>
>But Nix's point stands in that you're creating a race condition if
>you're trying to do anything with the file based on the permissions.

This is true, I assumed the OP just wanted to list the permissions. If
you want to actually do anything with the file, then it's often best to
just try, and to handle the bail-out in a sane manner if the access fails.

Since there are usually a zillion reasons for failure only one of which
is the permissions, you have a lot fewer cases to get right if you do
it this way. In day-to-day programming it's very rare that you need
to actually look at errno and to take differing action depending on
its value.

perror (man 3 perror - section 3 as it's a library function not a system
call) is very useful when trying to find out why your program doesn't
do what you assumed it would ....

Nick
--
http://www.leverton.org/blosxom ... So express yourself

Nix · External Since: Jul 29, 2004 Posts: 680

On 20 Jul 2007, Bruce Stephens uttered the following:
> ashu <ashishmourya21 RemoveThis @gmail.com> writes:
> [...]
>> actually it is not homework it is from old question paper and i m
>> trying to make it in C
>
> Unlikely time of the year for homework, I guess.
>
> But Nix's point stands in that you're creating a race condition if
> you're trying to do anything with the file based on the permissions.

It's not just the race that's the problem: after all, the worst someone
could do with that would be to trigger a DoS normally.

It's that there is no other portable way to tell. You could try a
comparison of your euid and uid with the owner and group of the file and
the permissions bits, but even that is torpedoed by the Linux-specific
concept of an fsuid (even if this generally == euid, it doesn't
necessarily, so if you're writing portable library code you can't assume
that), and by things like NFS servers with root_squash enabled, ACLs,
Kerberos or AFS tickets, or a myriad of other things, none of which will
affect your testing systems because of Sod's Law.

open() is the *only* reliable way. (Equally, if you want to determine
from a setuid or setgid program if the user on whose behalf you are
working has the right to open something, access() is the only way.)

--
`... in the sense that dragons logically follow evolution so they would
be able to wield metal.' --- Kenneth Eng's colourless green ideas sleep
furiously

Martin Gregorie · External Since: Aug 20, 2005 Posts: 284

ashu wrote:
> On Jul 21, 12:00 am, Nix <nix-razor-....TakeThisOut@esperi.org.uk> wrote:
>> On 20 Jul 2007, ashu verbalised:
>>
>>> i want to make a program that accept a file and chechs if it is
>>> readable and writable and give appropriate messeage ?
>>> i can make program to accpet filename from command line and open it
>>> in any omde and write data in it, but to know its permission is
>>> seems tricky, is there apecific function available ?
>> The only sane way to tell if you right now have permissions to open a
>> file is to use open(). Checking the permission bits to do this is silly.
>>
>> This does indeed smell like a homework assignment.
>>
>> (hm, I should have suggested unlink(), *snicker*)
>>
>> --
>> `... in the sense that dragons logically follow evolution so they would
>> be able to wield metal.' --- Kenneth Eng's colourless green ideas sleep
>> furiously
>
> actually it is not homework it is from old question paper and i m
> trying to make it in C
>
man 2 access

--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |

Nix · External Since: Jul 29, 2004 Posts: 680

On 21 Jul 2007, Martin Gregorie told this:
> man 2 access

That says if *the user on whose behalf you are operating* can open a
file. It doesn't say a thing about whether *you* can.

(i.e., it checks the uid, not the euid).

--
`... in the sense that dragons logically follow evolution so they would
be able to wield metal.' --- Kenneth Eng's colourless green ideas sleep
furiously

Ben Bacarisse · External Since: Jun 10, 2005 Posts: 90

Nix <nix-razor-pit DeleteThis @esperi.org.uk> writes:

> On 20 Jul 2007, Bruce Stephens uttered the following:
>> ashu <ashishmourya21 DeleteThis @gmail.com> writes:
>> [...]
>>> actually it is not homework it is from old question paper and i m
>>> trying to make it in C
>>
>> Unlikely time of the year for homework, I guess.
>>
>> But Nix's point stands in that you're creating a race condition if
>> you're trying to do anything with the file based on the permissions.
>
> It's not just the race that's the problem: after all, the worst someone
> could do with that would be to trigger a DoS normally.
>
> It's that there is no other portable way to tell. You could try a
> comparison of your euid and uid with the owner and group of the file and
> the permissions bits, but even that is torpedoed by the Linux-specific
> concept of an fsuid (even if this generally == euid, it doesn't
> necessarily, so if you're writing portable library code you can't assume
> that), and by things like NFS servers with root_squash enabled, ACLs,
> Kerberos or AFS tickets, or a myriad of other things, none of which will
> affect your testing systems because of Sod's Law.
>
> open() is the *only* reliable way. (Equally, if you want to determine
> from a setuid or setgid program if the user on whose behalf you are
> working has the right to open something, access() is the only way.)

Why use access from a setuid program? I would have thought that
access will fail to tell you the true story in that case as well. I
would have said opening the file is the only way in all cases. Am I
missing something?

--
Ben.

Nix · External Since: Jul 29, 2004 Posts: 680

On 21 Jul 2007, Ben Bacarisse outgrape:
> Nix <nix-razor-pit.TakeThisOut@esperi.org.uk> writes:
>> open() is the *only* reliable way. (Equally, if you want to determine
>> from a setuid or setgid program if the user on whose behalf you are
>> working has the right to open something, access() is the only way.)
>
> Why use access from a setuid program? I would have thought that
> access will fail to tell you the true story in that case as well. I
> would have said opening the file is the only way in all cases. Am I
> missing something?

Well, the point of access() isn't to answer the question `can I now open
this file in this way': it's to answer the question `can the person who
invoked me open this file in this way'. (Of course, unless you are
setuid/setgid, this is the same question, but if you are setuid/setgid
then it can be *very* different. Note that if you're setuid to non-root
it's quite possible that access() can say that your real uid can open a
file which you in fact cannot: of course you should switch uids back
before accessing it anyway...)

--
`... in the sense that dragons logically follow evolution so they would
be able to wield metal.' --- Kenneth Eng's colourless green ideas sleep
furiously

Ben Bacarisse · External Since: Jun 10, 2005 Posts: 90

Nix <nix-razor-pit DeleteThis @esperi.org.uk> writes:

> On 21 Jul 2007, Ben Bacarisse outgrape:
>> Nix <nix-razor-pit DeleteThis @esperi.org.uk> writes:
>>> open() is the *only* reliable way. (Equally, if you want to determine
>>> from a setuid or setgid program if the user on whose behalf you are
>>> working has the right to open something, access() is the only way.)
>>
>> Why use access from a setuid program? I would have thought that
>> access will fail to tell you the true story in that case as well. I
>> would have said opening the file is the only way in all cases. Am I
>> missing something?
>
> Well, the point of access() isn't to answer the question `can I now open
> this file in this way': it's to answer the question `can the person who
> invoked me open this file in this way'. (Of course, unless you are
> setuid/setgid, this is the same question, but if you are setuid/setgid
> then it can be *very* different. Note that if you're setuid to non-root
> it's quite possible that access() can say that your real uid can open a
> file which you in fact cannot: of course you should switch uids back
> before accessing it anyway...)

Sorry, you've lost me. I can't tell if you are agreeing with me that
access in an unreliable indicator of what one can do with a file, or if
you are offering further support for preferring access over open when
a program is setuid.

It seems to me that the bottom line is that the only way you can tell
if an operation will succeed is to try it. This is far from ideal
when the operation is compound (e.g. emptying two files but doing
neither if both can't be done) but anything else is just an educated
guess. You seemed to be saying that this is not the case when a
program is operating setuid, when access becomes the "only way". I
can't see how it is better than just trying.

--
Ben.

Nix · External Since: Jul 29, 2004 Posts: 680

On 23 Jul 2007, Ben Bacarisse stated:
> Nix <nix-razor-pit DeleteThis @esperi.org.uk> writes:
>> Well, the point of access() isn't to answer the question `can I now open
>> this file in this way': it's to answer the question `can the person who
>> invoked me open this file in this way'. (Of course, unless you are
>> setuid/setgid, this is the same question, but if you are setuid/setgid
>> then it can be *very* different. Note that if you're setuid to non-root
>> it's quite possible that access() can say that your real uid can open a
>> file which you in fact cannot: of course you should switch uids back
>> before accessing it anyway...)
>
> Sorry, you've lost me. I can't tell if you are agreeing with me that
> access in an unreliable indicator of what one can do with a file, or if
> you are offering further support for preferring access over open when
> a program is setuid.

Well, yes, of course access() is an unreliable indicator of what one can
do with a file: that's not what it's for. unlink() is an unreliable
indicator too. Smile

> It seems to me that the bottom line is that the only way you can tell
> if an operation will succeed is to try it. This is far from ideal
> when the operation is compound (e.g. emptying two files but doing
> neither if both can't be done) but anything else is just an educated
> guess.

Yes.

> You seemed to be saying that this is not the case when a
> program is operating setuid, when access becomes the "only way". I
> can't see how it is better than just trying.

If you have a setuid root program that, say, appends to a file, you'd
damn well better not just have it call open() or some sod is going to
use it to append a new line to /etc/passwd. You'd better call access()
first, to tell if *the person on whose behalf you are acting*, i.e., the
person whose real uid you still have, can open the file. But access()
isn't much use if you know you are not setuid or setgid: it just becomes
a racy way of telling you what open() will tell you anyway.

(This is only for those rare cases when you want to append to the file
*as root* rather than, say, just swapping your extra privileges out and
doing the work with euid == uid. This is sometimes the case.)

Is that clearer?

Ben Bacarisse · External Since: Jun 10, 2005 Posts: 90

Nix <nix-razor-pit.DeleteThis@esperi.org.uk> writes:

>> You seemed to be saying that this is not the case when a
>> program is operating setuid, when access becomes the "only way". I
>> can't see how it is better than just trying.
>
> If you have a setuid root program that, say, appends to a file,
> you'd damn well better not just have it call open() or some sod is
> going to use it to append a new line to /etc/passwd. You'd better
> call access() first, to tell if *the person on whose behalf you are
> acting*, i.e., the person whose real uid you still have, can open
> the file. But access() isn't much use if you know you are not
> setuid or setgid: it just becomes a racy way of telling you what
> open() will tell you anyway.

Just to be clear for other readers (I am sure you know this!) access
does not just tell you what open will. access("x", W_OK) may return 0
and yet open("x", O_WRONLY) may fail for all sorts of reasons (some of
which you quote previously as reasons not to use access). The
simplest one for testing purposes (at least for most Linux systems)
is to make the file append only.

> (This is only for those rare cases when you want to append to the file
> *as root* rather than, say, just swapping your extra privileges out and
> doing the work with euid == uid. This is sometimes the case.)
>
> Is that clearer?

Yes. I now do see the usage case you propose but I would still argue
against using access in that case. In fact the argument seems to me
to be stringer since the race (which is always there, of course)
becomes more dangerous if you are setuid root (or, indeed, setuid
anything though the risks are consequently lower). If you do:

if (access("safefile", R_W) == 0) && (f = fopen("safefile", "a"))) {
...
}

you provide a window in which a malicious user can do

rm safefile; ln /etc/passwd safefile

so I am still struggling to see when one would really advocate its use.

--
Ben.