View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0004274 | unreal | ircd | public | 2014-03-14 01:14 | 2014-03-14 01:14 |
| Reporter | peterkingalexander | Assigned To | ohnobinki | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Platform | ppc | OS | Mac OSX | OS Version | 10.4.8 |
| Product Version | 3.2.6 | ||||
| Fixed in Version | 3.2.9-RC1 | ||||
| Summary | 0004274: improper use of mode_t for DEFAULT_PERMISSIONS in chmod and open operations | ||||
| Description | For 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 Reproduce | on 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 :) | ||||
| Tags | No tags attached. | ||||
| Attached Files | |||||
| 3rd party modules | |||||
|
|
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 |
|
|
0600 points out it's octal in C - i noticed this some weeks ago myself. Try printf("%i %i\n", 0600, 600) |
|
|
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 |
|
|
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 |
|
|
Yes this is an OS X bug. I think I heard about it before (don't know if it was ever reported, though). |
|
|
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. |
|
|
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. |
|
|
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 |
|
|
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) |
|
|
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 |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2014-03-14 01:14 | peterkingalexander | New Issue | |
| 2014-03-14 01:14 | peterkingalexander | Issue generated from: 0003189 |
