It is currently Thu, 20 Jan 2022 04:16:46 GMT

Author Message
 wierd file permissions
In article <ap7qr9$>, says...

There is a "file permissions mask" (see umask for further details) which
is applied to file creation operations. That might be part of the

I believe the "S" permission is the "sticky bit" (keep program in memory
after execution completes)


Barry Kimelman
Winnipeg, Manitoba, Canada
email :

 Mon, 11 Apr 2005 20:56:08 GMT   
 wierd file permissions

The S (capital) in this position means that the set-user-ID bit is on, but
there is no execution permission for the user. In other words, a meaningless
combination. If both bits were on, it would have been a small s.

The mask clears bits. So it could have not set the set-user-ID bit, but it
could have cleared the user-execute bit.

It would be helpful to see the ACTUAL creat or open call that created the
file, not one typed into a mail message. I'll bet the permissions are not
really 0600. Also, the file-creation mask.


P.S. The man page for ls is very informative about what the various letters

 Mon, 11 Apr 2005 21:38:25 GMT   
 wierd file permissions

use creat("sometextfile",0600);

All men are frauds. The only difference between them is that some admit it.
I myself deny it.
H. L. Mencken (1880 - 1956)

 Tue, 12 Apr 2005 00:54:24 GMT   
 wierd file permissions


Don't understand. Why would that help?


 Tue, 12 Apr 2005 01:45:27 GMT   
 wierd file permissions

Read man page for open(2). With open you have to specify O_RDONLY, O_RDWR
or O_WRONLY and you can specify O_CREAT as well, but you can't use O_CREAT
alone. Linux man page for open() specify that creat is equivalent to open
with flags equal to O_CREAT|O_WRONLY|O_TRUNC.

HTH, Dragan

Dragan Cvetkovic,

To be or not to be is true. G. Boole      No it isn't.  L. E. J. Brouwer

 Tue, 12 Apr 2005 02:00:59 GMT   
 wierd file permissions

Yes, I understand that much. However:

1. It is impossible for the system to detect the presence or absence of the
O_RDONLY flag, as it is always implemented as 0. (Not required by the
standards, but a tradition.) That's why they're values, not flags, and why
O_RDWR is even there--if the other two were really flags, you could just say

2. Even if Linux defined O_RDONLY as something other than 0, or decided it
didn't like the combination of O_RDONLY | O_CREAT (which I admit is very
strange), why would it create the file with the funny mode? That's what I
was referring to when I asked, "Why would that help?"


 Tue, 12 Apr 2005 02:13:55 GMT   
 wierd file permissions

I have tried fd = open(name, O_CREAT, 0600) on Linux, Solaris 8 and AIX 4.2
and in all cases it would create the file (!) but the permissions would be
0600 (my umask is 022).

But it seems it would really do O_RDONLY | O_CREAT since I couldn't write
to that file (EBADF).

Now, why would anybody want this, I can't really explain.

OK I can, if you just want to create a file as a lock or something, just as
if issuing touch on a command prompt.


P.S. There is a following paragraph in a latest OpenGroup specification for

      In historical implementations the value of O_RDONLY is zero. Because of
      that, it is not possible to detect the presence of O_RDONLY and
      another option. Future implementations should encode O_RDONLY and
      O_WRONLY as bit flags so that:


so there might be a hope :-)

Dragan Cvetkovic,

To be or not to be is true. G. Boole      No it isn't.  L. E. J. Brouwer

 Tue, 12 Apr 2005 02:39:03 GMT   
 wierd file permissions
Thanks for the reply! I just didn't think it was fair for me to be confused
and you not to be confused. ;-)


 Tue, 12 Apr 2005 02:58:58 GMT   
 wierd file permissions


Programmers all over the world, unite in confusion :-)

Bye, Dragan

Dragan Cvetkovic,

To be or not to be is true. G. Boole      No it isn't.  L. E. J. Brouwer

 Tue, 12 Apr 2005 03:06:50 GMT   
 wierd file permissions
In article <>,
Dragan Cvetkovic  <> wrote:

Don't hold your breath.  Any vendor that wishes to maintain binary
back-compatibility will probably not make that change.  So you're only
likely to see it in brand new implementations that don't have anything they
need to be compatible with.

Barry Margolin,
Genuity, Woburn, MA
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

 Tue, 12 Apr 2005 02:52:46 GMT   
 wierd file permissions

It is, of course, possible, that the original user first created
the file with:

        open("file", O_CREAT);

then fixed his code but the file now already exists
and has bogus permissions.

        open("file", O_CREAT, 600);

does not quite give that strange mode.

Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

 Tue, 12 Apr 2005 03:31:40 GMT   
 wierd file permissions

"Casper H.S. Dik" <Casper....@Sun.COM> wrote in message

Your is an excellent theory. open() is one of the few system calls where the
third argument is optional. Mandatory with O_CREAT, of course, but the
compiler wouldn't know that.


 Tue, 12 Apr 2005 03:41:37 GMT   
 wierd file permissions


I agree with Marc Rochkind, who suggested posting the actual code.  If you
could post the entire program, the problem might become more apparent.

Does your program check for the return value from open()?  With the current
permissions on the file, your open() will always fail with EACCES ("oflag
permission is denied for an existing file"), since you're asking for read
permission (O_RDONLY is 0 so O_CREAT is equivalent to O_RDONLY|O_CREAT, as
others have pointed out), and the existing file only has write permission.
Perhaps the file was already there (maybe from a prior run of your
program?), and then you subsequently performed a chmod() with mode 04204?

If you remove the file and then re-run your program, does the file get
created with the proper permissions?  If so, then it sounds like you did a
chmod() sometime after the original creation of the file (perhaps your
program used to have a chmod() in it which you've subsequently removed?).
If removing the file and re-running your program still results in the odd
permissions, then it sounds like you've still got a bug, in which case
posting the entire program would help.

The only other thing I can think of might be if this is an NFS filesystem on
some strange file server, where that server has some reason for giving you
different permissions than you've asked for.

- Greg Porr, NCR Corporation

 Tue, 12 Apr 2005 04:38:52 GMT   
 wierd file permissions

Thanks for all those who replied to this question.

The problem is resolved now.
The trouble making code was:

Both answers
seem to work!

* There was no problem with umask. By default umask was set to 0002.
I tried it to exclusivey set it by umask system call, but it did not help.
* All code tested on RH8
* write-protected file "sometextfile" was deleted between various instances
of execution.

This reasoning does not work!! Consecutive calls to above open statement  
fails if the file already exists and has permissions --wS---r--

Thanks again!

 Tue, 12 Apr 2005 10:38:14 GMT   
   [ 20 post ]  Go to page: [1] [2]

Similar Threads

1. NFS, mail and file permissions, wierd problem...

2. wierd permissions problem running pppd

3. HELP - wierd directory permission problem!

4. wierd stuffs in proxy log file and back end server log file

5. file permissions/permission execution

6. How to reset permissions on file with no read permissions

7. Changing permissions on file underlying the mount point without unmounting file system

8. ftpd, default file permissions on creating a file on Solaris, SunOS 5.5.1

Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Designed by ST Software