Very Computer

by **John H. Chauv** » Mon, 31 May 1993 09:14:27

I have been following this thread but I am still a little
confused about the best procedure to use to check file
permissions. For example, lets say you have an application
that is owned by root but does NOT have the set user ID or
set group ID bits set. What is the correct procedure to
check if a file:
(1) exists
(2) user has read access
(3) user has write access

Obvious, the open() command will determine if a file has the
right permissions. But, in my case, I do not need to open
the file ( it will be open by another application ). Is
it possible to duplicate the file access test performed
by the open() command without using the open() command? The
access() command test accessibility based on the real user
ID and the real group ID which is not how the open()
command works.(it uses the effective user ID). Plus, it
has been mentioned in this thread that it should not be
used. So it appears that access() is not the best solution.
How about the stat() command? Should I just give up and use
the open() to check if the has the right permissions since
it is the final authority? An example would be appreciated.

How is the permission check effected by the su program. If
user Joe logs on and then su over to Bob and executes my
program will the file checks use Bob or Joe ID?

I am using a Silicon Graphics workstation running IRIX 4.0.5.

Thanks for the help,

John Chauvin

Cerritos, California

--

Netcom - Online Communication Services San Jose, CA

by **Barry Margol** » Mon, 31 May 1993 11:36:11

Quote:>Obvious, the open() command will determine if a file has the
>right permissions. But, in my case, I do not need to open
>the file ( it will be open by another application ). Is
>it possible to duplicate the file access test performed
>by the open() command without using the open() command? The
>access() command test accessibility based on the real user
>ID and the real group ID which is not how the open()
>command works.(it uses the effective user ID).

But you said that the program isn't set-[ug]id, so r[ug]id == e[ug]id.

Quote:> Plus, it
>has been mentioned in this thread that it should not be
>used. So it appears that access() is not the best solution.
>How about the stat() command?

Stat() doesn't check access; you'd have to do this yourself by examining
the owner, group, and mode yourself, duplicating what is done in access().

Quote:> Should I just give up and use
>the open() to check if the has the right permissions since
>it is the final authority? An example would be appreciated.

The problem Chris Torek kept bringing up is that *any* access check ahead
of time introduces a problem. If you check first and then the file is
opened again later, the permissions or existence of the file could change
between the check and the open. Since the routine that calls open has to
be prepared for failure, why bother making an extra check ahead of time?

Quote:>How is the permission check effected by the su program. If
>user Joe logs on and then su over to Bob and executes my
>program will the file checks use Bob or Joe ID?

Su changes both the real and effective uid, so all access checks will use
the Bob ID.
--
Barry Margolin
System Manager, Thinking Machines Corp.

by **John H. Chauv** » Tue, 01 Jun 1993 00:44:06

) writes:
>>Obvious, the open() command will determine if a file has the
>>right permissions. But, in my case, I do not need to open
>>the file ( it will be open by another application ). Is
>>it possible to duplicate the file access test performed
>>by the open() command without using the open() command? The
>>access() command test accessibility based on the real user
>>ID and the real group ID which is not how the open()
>>command works.(it uses the effective user ID).

>But you said that the program isn't set-[ug]id, so r[ug]id == e[ug]id.

Sorry about the confusion. My mistake. My reason for mentioning
access() uses effective and not real user ID's is to point
out that access() test accessibility different then open() implying
that there may be other differences which might
indicate that access() is not the right command to use.

Quote:>> Plus, it
>>has been mentioned in this thread that it should not be
>>used. So it appears that access() is not the best solution.
>>How about the stat() command?

>Stat() doesn't check access; you'd have to do this yourself by examining
>the owner, group, and mode yourself, duplicating what is done in access().

I realize that I have to check the structure return by stat(). My question
really is: Should I use the stat() command to determine access or
is the access() sufficient? There seems to be a dislike for the access() and
I really do not understand why. Doesn't the access() command use stat() to
determine access? Why would one use the stat() command instead of access()?

Quote:>> Should I just give up and use
>>the open() to check if the has the right permissions since
>>it is the final authority? An example would be appreciated.

>The problem Chris Torek kept bringing up is that *any* access check ahead
>of time introduces a problem. If you check first and then the file is
>opened again later, the permissions or existence of the file could change
>between the check and the open. Since the routine that calls open has to
>be prepared for failure, why bother making an extra check ahead of time?

In the environment that my application will be used this is not a problem.
I need to let the user know immediately after selecting a file that he
has a permission problem. The user is required to provide up to 10 filenames
as input to a program. He does not want to provide all 10 filenames and
then find out that the first one has a problem. I realize this not the
best solution and that it is possible for the open() to fail.

>>How is the permission check effected by the su program. If
>>user Joe logs on and then su over to Bob and executes my
>>program will the file checks use Bob or Joe ID?

>Su changes both the real and effective uid, so all access checks will use
>the Bob ID.
>--
>Barry Margolin
>System Manager, Thinking Machines Corp.

As you can probably tell, I new to UNIX programming. I am just trying to
determine the correct/best way to accomplish this task.

Thanks for all the help and patience!i

John Chauvin

Cerritos, California

A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A

--

Netcom - Online Communication Services San Jose, CA

by **Lawrence Kir** » Tue, 01 Jun 1993 04:21:06

> Chauvin
>) writes:
>>>Obvious, the open() command will determine if a file has the
>>>right permissions. But, in my case, I do not need to open
>>>the file ( it will be open by another application ). Is
>>>it possible to duplicate the file access test performed
>>>by the open() command without using the open() command? The
>>>access() command test accessibility based on the real user
>>>ID and the real group ID which is not how the open()
>>>command works.(it uses the effective user ID).

>>But you said that the program isn't set-[ug]id, so r[ug]id == e[ug]id.

What about if the program which exec'd it was set-[ug]id? Unless a program
actually sets the effective IDs to the real IDs they might still be different.

.
.
.

Quote:>I realize that I have to check the structure return by stat(). My question
>really is: Should I use the stat() command to determine access or
>is the access() sufficient? There seems to be a dislike for the access() and
>I really do not understand why. Doesn't the access() command use stat() to
>determine access? Why would one use the stat() command instead of access()?

The issue is that access() tests the real user IDs. If that is what you want
then use it, but it is only useful in a few, rare, circumstances. Normally
you want to test the effective IDs (since that is what open() checks) and
unless you are absolutely sure that the read and effective IDs are identical,
you can't use access(). For this reason and the fact that it doesn't guarantee
anything for any operation done afterwards on the file mean that it isn't
generally very useful. The version of Unix I have provides eaccess() to
test against effective user IDs but this doesn't appear to be standard.

Quote:
>>> Should I just give up and use
>>>the open() to check if the has the right permissions since
>>>it is the final authority? An example would be appreciated.

It seems the best way to go. To use stat you're going to have to do a fair
amount of fiddling including reading the effective IDs of the process. With
the amount you are going to use them open()/close() aren't going to hit system
performance!

Quote:>In the environment that my application will be used this is not a problem.
>I need to let the user know immediately after selecting a file that he
>has a permission problem. The user is required to provide up to 10 filenames
>as input to a program. He does not want to provide all 10 filenames and
>then find out that the first one has a problem. I realize this not the
>best solution and that it is possible for the open() to fail.

It's quite reasonable to do this in an advisory way.

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

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

by **Christoph Badu** » Wed, 02 Jun 1993 03:18:48

Quote:>I realize that I have to check the structure return by stat(). My question
>really is: Should I use the stat() command to determine access or
>is the access() sufficient? There seems to be a dislike for the access() and
>I really do not understand why. Doesn't the access() command use stat() to
>determine access? Why would one use the stat() command instead of access()?

Access() doesn't call stat(). Both are system calls and implemented
in the kernel.

There are two problems. If the real uid doesn't equal the effective
uid access() returns the wrong answer. You can circumvent this
problem if you emulate access() with stat(). Even when you emulate it
with stat() that doesn't get you rid of the second problem namely that
the file permissions might change or the file might vanish between the
call to access()/stat() and the call to open.

Quote:>In the environment that my application will be used this is not a problem.

Well, you have been warned.

Quote:>I need to let the user know immediately after selecting a file that he
>has a permission problem. The user is required to provide up to 10 filenames
>as input to a program. He does not want to provide all 10 filenames and
>then find out that the first one has a problem. I realize this not the
>best solution and that it is possible for the open() to fail.

The "right" way to handle this is to open() the files as the user
inputs their names and later use the already opened file descriptors.
Alas this works only if the number of files to be opened is small
because many UNIX implementations have rather low limits on the number
of files a process can have open simultaneously (as low as 20).

--

Personally, I don't care whether someone is cool enough to quote Doug
Gwyn--I only care whether Doug Gwyn is cool enough to quote. -- Larry Wall

Very Computer

Confused about file access (Was: Does a file exist?)

Confused about file access (Was: Does a file exist?)

Confused about file access (Was: Does a file exist?)

Confused about file access (Was: Does a file exist?)

Confused about file access (Was: Does a file exist?)

Confused about file access (Was: Does a file exist?)