View Issue Details

IDProjectCategoryView StatusLast Update
0003189unrealircdpublic2013-12-08 05:11
ReporterTommyTheKid Assigned Toohnobinki  
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
PlatformppcOSMac OSXOS Version10.4.8
Product Version3.2.6 
Fixed in Version3.2.9-RC1 
Summary0003189: improper use of mode_t for DEFAULT_PERMISSIONS in chmod and open operations
DescriptionFor some reason, on the mac, ./include/setup.h has a line:

#define DEFAULT_PERMISSIONS 600

(its missing the leading zero)

.. I am not sure *why* that happens, or whether it affects more than just OSX 10.4, but it lead to me discovering that putting 0600 is not really a proper use of "mode_t" for chmod/open operations.

As per the following man page...

[man 2 chmod]
CHMOD(2) BSD System Calls Manual CHMOD(2)

NAME
     chmod, fchmod -- change mode of file

SYNOPSIS
     #include <sys/types.h>
     #include <sys/stat.h>

     int
     chmod(const char *path, mode_t mode);

     int
     fchmod(int fd, mode_t mode);

DESCRIPTION
     The function chmod() sets the file permission bits of the file specified
     by the pathname path to mode. Fchmod() sets the permission bits of the
     specified file descriptor fd. Chmod() verifies that the process owner
     (user) either owns the file specified by path (or fd), or is the super-
     user. A mode is created from or'd permission bit masks defined in
     <sys/stat.h>:
           #define S_IRWXU 0000700 /* RWX mask for owner */
           #define S_IRUSR 0000400 /* R for owner */
           #define S_IWUSR 0000200 /* W for owner */
           #define S_IXUSR 0000100 /* X for owner */

           #define S_IRWXG 0000070 /* RWX mask for group */
           #define S_IRGRP 0000040 /* R for group */
           #define S_IWGRP 0000020 /* W for group */
           #define S_IXGRP 0000010 /* X for group */

           #define S_IRWXO 0000007 /* RWX mask for other */
           #define S_IROTH 0000004 /* R for other */
           #define S_IWOTH 0000002 /* W for other */
           #define S_IXOTH 0000001 /* X for other */

           #define S_ISUID 0004000 /* set user id on execution */
           #define S_ISGID 0002000 /* set group id on execution */
           #define S_ISVTX 0001000 /* save swapped text even after use */
[snip]

(this was from Mac OSX, but Linux, Solaris and others have extremely similar information)

... DEFAULT_PERMISSIONS should be defined as:

#define DEFAULT_PERMISSIONS (S_IRUSR|S_IWUSR)


** this might even allow the "DEFAULT_PERMISSIONS" to work on other OS's like "d0ze" ?
Steps To Reproduceon OSX? maybe others?

run ./Confg
(select defaults)
.. verify as the system runs ./configure, there is a --with-permissions=0600

.. somewhere during ./configure, the leading zero gets lost (at least on Mac OSX)

look at ./include/setup.h, if DEFAULT_PERMISSIONS is "600" and not "0600" ircd will not start, cause it will chmod your unrealircd.conf file to look like:

---x-wx--T 1 ircdev ircdev 3665 Jan 4 18:17 unrealircd.conf

.. which is not readable.

---x-wx--T -> 1130
 ... curiously if you do printf("%o\n", 600); you get 1130 :)

TagsNo tags attached.
Attached Files
configure.patch (343 bytes)
3rd party modules

Relationships

related to 0003489 closed Errors "1" and "2" when making (Mac OS X/Leopard) 
child of 0003776 resolvedsyzop Unreal3.2.9 TODO 

Activities

TommyTheKid

2007-01-04 21:20

reporter   ~0012998

ugh, for what its worth, you can specify "0" for the default permissions to work around this, or modify ./include/setup.h to add the leading zero to the DEFAULT_PERMISSIONS.. or if you desire, properly define it (S_IRUSR|S_IWUSR)

~tommy

stskeeps

2007-01-05 04:09

reporter   ~0013001

0600 points out it's octal in C - i noticed this some weeks ago myself.

Try printf("%i %i\n", 0600, 600)

TommyTheKid

2007-01-05 11:12

reporter   ~0013005

For those that have not figured this out, and I meant to paste this output above... HERE is what it looks like when this bug manifests itself.

$ ./unreal start
Starting UnrealIRCd
 _ _ _ ___________ _____ _
| | | | | |_ _| ___ \/ __ \ | |
| | | |_ __ _ __ ___ __ _| | | | | |_/ /| / \/ __| |
| | | | '_ \| '__/ _ \/ _` | | | | | / | | / _` |
| |_| | | | | | | __/ (_| | |_| |_| |\ \ | \__/\ (_| |
 \___/|_| |_|_| \___|\__,_|_|\___/\_| \_| \____/\__,_|
                           v3.2.6
                     using TRE 0.7.2 (GPL)
                     using OpenSSL 0.9.7l 28 Sep 2006

* Loading IRCd configuration ..
[error] Couldn't open "unrealircd.conf": Permission denied
[error] Could not load config file unrealircd.conf
[error] IRCd configuration failed to load
Possible error encountered (IRCd seemingly not started)
=====================================================
Check above for possible errors, and this output of
ircd.log. If you cannot solve the problem, read
Unreal.nfo on where to get support
=====================================================
[Thu Jan 4 19:34:23 2007] - TIME SYNCH: timeserver=1167968063, our=1167968063, offset = 0 [old offset: 0]

$ ls -l unrealircd.conf
---x-wx--T 1 ircdev ircdev 3665 Jan 5 09:05 unrealircd.conf


Again, this is due to the (shell|autoconf|somethingelse?) treating the --with-permissions=0600 like a regular (decimal) number and "simplifying" it to 600 on assignment to the variable $with-permissions (which for some reason is assigned to $withval) and added to the .h file incorrectly during the configure script.

http://www.google.com/search?q=600+in+octal
600 = 0o1130

~tommy

TommyTheKid

2007-01-05 12:14

reporter   ~0013006

I have included a temporary patch (configure.patch) that changes one line in ./configure

(slightly modified to make more sense and protect the innocent)

[10:53:50] <TommyTheKid> ac_optarg=`expr "x$ac_option" : 'x[^=]*=\(.*\)'` <-- there is where it gets botched
[10:54:16] <TommyTheKid> mini:~ ircdev$ ac_optarg=`expr "x$ac_option" : 'x[^=]*=\(.*\)'`
[10:54:16] <TommyTheKid> mini:~ ircdev$ echo $ac_optarg
[10:54:16] <TommyTheKid> 600
[10:54:16] <TommyTheKid> mini:~ ircdev$ echo $ac_option
[10:54:16] <TommyTheKid> --with-permissions=0600

[10:54:48] <satmd> it's the expr in there

[10:56:24] <satmd> how about echo "x$ac_option" | sed 's,x[^=]*=\(.*\),\1,' ?

[10:57:11] <satmd> TommyTheKid's expr isn't broken
[10:57:18] <satmd> it just handles numbers as numbers
[10:57:25] <satmd> - stripping leading zeros
[10:57:29] <TommyTheKid> satmd: it does work (come up with 0600)
[10:57:31] <satmd> :)
[10:58:07] <satmd> would you please submit it as a bug and include it in patch format?



*** This resolves the "issue" that I am experiencing, and should probably work OK for most POSIX complaint machines, but at some point someone should look into the proper use of chmod(2)

~tommy

syzop

2007-01-06 15:51

administrator   ~0013010

Yes this is an OS X bug. I think I heard about it before (don't know if it was ever reported, though).

syzop

2010-07-14 17:53

administrator   ~0016178

We should fix this in 3.2.9, or was this already addressed? There were some mac fixed in the past few years... might even be fixed before 3.2.8?
Note that part of the bug is the missing 0 (somehow), and not something like a bad syscall/function.

ohnobinki

2010-07-14 18:42

reporter   ~0016182

I just tested CVS and 3.2.8.1 on Mac OSX 10.5.8 and this issue still exists. From satmd's patch, I wonder if this is an autoconf bug.

ohnobinki

2010-08-17 19:22

reporter   ~0016283

I know that satmd wrote essentially the following somewhere, but I want to record it for myself here. The problem is a bug in Mac OSX's expr(1) program:

peter-krakers-mac-mini:unreal binki$ /bin/expr X--enable-permissions=0660 : '[^=]*\(.*\)'
=0660
peter-krakers-mac-mini:unreal binki$ /bin/expr X--enable-permissions=0660 : '[^=]*=\(.*\)'
660

ohnobinki

2010-08-19 03:06

reporter   ~0016284

I filed a bug against Mac OSX, but I think the below solution is better for two reasons.

First, it should stop this problem from happening on Mac OSX -- including old versions (even if a new OS X actually was fixed by Apple...). Secondly, it will act like chmod(1) which users are more used to using (where chmod 600 myfile is the same as chmod 0600 myfile). I'm quite sure that an extra zero in front of the value (i.e., 0600 now becomes 00600 on Linux or machines with non-buggy expr(1) programs) can't possibly cause anyone harm ;-).

- Prepend a `0' to the begining of --with-permission, working around a Mac OS X bug and hiding the fact that chmod()'s params are octal from users. (0003189)

ohnobinki

2013-12-08 05:11

reporter   ~0017856

For the historical record, this bug is supposed to be fixed in Mac OS X 10.8 (I was only able to test/verify that Mac OS X 10.9’s userspace is fixed). http://openradar.appspot.com/8319378

Issue History

Date Modified Username Field Change
2007-01-04 21:17 TommyTheKid New Issue
2007-01-04 21:20 TommyTheKid Note Added: 0012998
2007-01-05 04:09 stskeeps Note Added: 0013001
2007-01-05 11:12 TommyTheKid Note Added: 0013005
2007-01-05 12:10 TommyTheKid File Added: configure.patch
2007-01-05 12:14 TommyTheKid Note Added: 0013006
2007-01-06 15:51 syzop Note Added: 0013010
2007-01-06 15:51 syzop Status new => acknowledged
2007-11-19 13:45 syzop Relationship added related to 0003489
2010-07-14 17:52 syzop Relationship added child of 0003776
2010-07-14 17:53 syzop Note Added: 0016178
2010-07-14 18:42 ohnobinki Note Added: 0016182
2010-08-15 06:52 ohnobinki Status acknowledged => assigned
2010-08-15 06:52 ohnobinki Assigned To => ohnobinki
2010-08-17 19:22 ohnobinki Note Added: 0016283
2010-08-19 03:06 ohnobinki QA => Not touched yet by developer
2010-08-19 03:06 ohnobinki U4: Need for upstream patch => No need for upstream InspIRCd patch
2010-08-19 03:06 ohnobinki Note Added: 0016284
2010-08-19 03:06 ohnobinki Status assigned => resolved
2010-08-19 03:06 ohnobinki Fixed in Version => 3.2.9-RC1
2010-08-19 03:06 ohnobinki Resolution open => fixed
2013-12-08 05:11 ohnobinki Note Added: 0017856
2014-03-14 01:14 peterkingalexander Issue cloned: 0004274