bug#10021: [PATCH id] Add error-checking on GNU
Here are proposed patches for the other coreutils applications
that invoke getuid et al.
port to GNU hosts, where getuid and friends can fail
* src/groups.c (main):
* src/install.c (need_copy):
* src/su.c (log_su):
* src/test.c (unary_operator):
* src/whoami.c (main):
Don't assume that getuid and friends always succeed.
This fixes the same problem that we recently fixed with 'id'.
diff --git a/src/groups.c b/src/groups.c
index abb7bc7..279b831 100644
--- a/src/groups.c
+++ b/src/groups.c
@@ -97,9 +97,23 @@ main (int argc, char **argv)
if (optind == argc)
{
/* No arguments. Divulge the details of the current process. */
+ uid_t NO_UID = -1;
+ gid_t NO_GID = -1;
+
+ errno = 0;
ruid = getuid ();
+ if (ruid == NO_UID errno)
+error (EXIT_FAILURE, errno, _(cannot get real UID));
+
+ errno = 0;
egid = getegid ();
+ if (egid == NO_GID errno)
+error (EXIT_FAILURE, errno, _(cannot get effective GID));
+
+ errno = 0;
rgid = getgid ();
+ if (rgid == NO_GID errno)
+error (EXIT_FAILURE, errno, _(cannot get real GID));
if (!print_group_list (NULL, ruid, rgid, egid, true))
ok = false;
diff --git a/src/install.c b/src/install.c
index dbff9c9..94534f8 100644
--- a/src/install.c
+++ b/src/install.c
@@ -192,9 +192,27 @@ need_copy (const char *src_name, const char *dest_name,
return true;
if (src_sb.st_size != dest_sb.st_size
- || (dest_sb.st_mode CHMOD_MODE_BITS) != mode
- || dest_sb.st_uid != (owner_id == (uid_t) -1 ? getuid () : owner_id)
- || dest_sb.st_gid != (group_id == (gid_t) -1 ? getgid () : group_id))
+ || (dest_sb.st_mode CHMOD_MODE_BITS) != mode)
+return true;
+
+ if (owner_id == (uid_t) -1)
+{
+ errno = 0;
+ uid_t ruid = getuid ();
+ if ((ruid == (uid_t) -1 errno) || dest_sb.st_uid != ruid)
+return true;
+}
+ else if (dest_sb.st_uid != owner_id)
+return true;
+
+ if (group_id == (uid_t) -1)
+{
+ errno = 0;
+ gid_t rgid = getgid ();
+ if ((rgid == (uid_t) -1 errno) || dest_sb.st_gid != rgid)
+return true;
+}
+ else if (dest_sb.st_gid != group_id)
return true;
/* compare SELinux context if preserving */
diff --git a/src/su.c b/src/su.c
index 081ecb2..b1ba2a7 100644
--- a/src/su.c
+++ b/src/su.c
@@ -173,7 +173,10 @@ log_su (struct passwd const *pw, bool successful)
{
/* getlogin can fail -- usually due to lack of utmp entry.
Resort to getpwuid. */
- struct passwd *pwd = getpwuid (getuid ());
+ errno = 0;
+ uid_t ruid = getuid ();
+ uid_t NO_UID = -1;
+ struct passwd *pwd = (ruid == NO_UID errno ? NULL : getpwuid (ruid));
old_user = (pwd ? pwd-pw_name : );
}
tty = ttyname (STDERR_FILENO);
diff --git a/src/test.c b/src/test.c
index 362df65..1b06ca8 100644
--- a/src/test.c
+++ b/src/test.c
@@ -414,13 +414,21 @@ unary_operator (void)
case 'O': /* File is owned by you? */
unary_advance ();
- return (stat (argv[pos - 1], stat_buf) == 0
- (geteuid () == stat_buf.st_uid));
+ if (stat (argv[pos - 1], stat_buf) != 0)
+return false;
+ errno = 0;
+ uid_t euid = geteuid ();
+ uid_t NO_UID = -1;
+ return ! (euid == NO_UID errno) euid == stat_buf.st_uid;
case 'G': /* File is owned by your group? */
unary_advance ();
- return (stat (argv[pos - 1], stat_buf) == 0
- (getegid () == stat_buf.st_gid));
+ if (stat (argv[pos - 1], stat_buf) != 0)
+return false;
+ errno = 0;
+ gid_t egid = getegid ();
+ gid_t NO_GID = -1;
+ return ! (egid == NO_GID errno) egid == stat_buf.st_gid;
case 'f': /* File is a file? */
unary_advance ();
diff --git a/src/whoami.c b/src/whoami.c
index e563dcf..1b0c3cd 100644
--- a/src/whoami.c
+++ b/src/whoami.c
@@ -61,6 +61,7 @@ main (int argc, char **argv)
{
struct passwd *pw;
uid_t uid;
+ uid_t NO_UID = -1;
initialize_main (argc, argv);
set_program_name (argv[0]);
@@ -81,8 +82,9 @@ main (int argc, char **argv)
usage (EXIT_FAILURE);
}
+ errno = 0;
uid = geteuid ();
- pw = getpwuid (uid);
+ pw = (uid == NO_UID errno ? NULL : getpwuid (uid));
if (pw)
{
puts (pw-pw_name);
bug#10055: [sr #107875] BUG cp -u corrupts 'fs'' information if interupted; can't recover on future invoctions
Jim Meyering wrote: Linda A. Walsh wrote: Hmmm Dang strange processes on bugs... can't submit directly bug can just by emailing it to the email list? ... (bureaucracy!) Linda Walsh wrote: This should be filed under bugs, not under support, but it seems that users of the core utilis are ot allowed to find bugs...convenient. Thanks for the report. Please do not use savannah's bug or support interfaces for coreutils. We deliberately disabled the former. Now, when you send a message to the bug-coreutils mailing list, it creates a ticket for you. Yours is here: [1]http://bugs.gnu.org/10055 Simply replying to any mail about it adds entries to its log. But that's not the bug db interface...thats just a log...where? the bug db intface for the bug in the bug database? References 1. http://bugs.gnu.org/10055
bug#10055: [sr #107875] BUG cp -u corrupts 'fs'' information if interupted; can't recover on future invoctions
Linda A. Walsh wrote: ... But that's not the bug db interface...thats just a log...where? the bug db intface for the bug in the bug database? References 1. http://bugs.gnu.org/10055 Here's a description of the interface: http://debbugs.gnu.org/
bug#9939: Problems with the SIZE description in man pages for ls and du
On 11/15/2011 07:35 PM, Rüdiger Meier wrote: On Tuesday 15 November 2011, Eric Blake wrote: From e36e6f2c6e95d6e23be805f7bab6c596b1818d22 Mon Sep 17 00:00:00 [...] -SIZE is an integer with an optional suffix (example: 10MB). Suffixes are:\n\ -KB 1000, K 1024, MB 1000*1000, M 1024*1024, and so on for G, T, P, E, Z, Y.\n\ +SIZE is an integer and optional unit (example: 10M is 10*1024*1024). Units\n\ +are K, M, G, T, P, E, Z, Y (powers of 1024) or KB, MB, ... (powers of 1000).\n\ Reviewing this I see that the case unit only without int is not documented now. This has been changed already in 50e5d024. Yes, and we made the change intentionally. Probably no problem because it's only --help and not info page. Just want to note that. Well, it's also the man page; but again, --help and man output are for concise references, focusing on just enough to get the job done, whereas the info page is the full documentation and does cover the alternative. Saying and/or instead of and could make it narrowly but still not 100% exactly and more confusing again. I think we've already hit a good balance of conciseness vs. understandability, and tweaking things to mention unit without int in the --help output seems counterproductive at this point. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
bug#10019: sort options -Mn are incompatible
On 11/12/2011 02:29 PM, Paul Eggert wrote: On 11/12/11 05:54, Eric Blake wrote: -k --key=KEYDEF control where a key starts and ends, and give ordering specific to the key. See KEYDEF below. KEYDEF is F[.C][OPTS][,F[.C][OPTS]], where F is a field number and C a character position in the field; both are origin 1. If the second position is omitted, the key runs to the end of the line. If neither -t nor -b is in effect, characters in a field are counted from the beginning of the preceding whitespace. OPTS is one or more single-letter ordering options [bdfgiMhnRrV], which override global ordering options for that key. If no key is given, use the entire line as the key. That's nicer, but a bit longer. How about this attempt to shorten its first two sentences? -k, --key=KEYDEF sort via a key; KEYDEF gives location and type ... KEYDEF is F[.C][OPTS][,F[.C][OPTS]], where F is a field number and C a character position in the field; both are origin 1, and the key's end defaults to the line's end. with the remainder as before. Sure. Here's the current state of things in patch format; any last objections before I push this? From 968b21312eda99fd5e9402546c370775d1e696cf Mon Sep 17 00:00:00 2001 From: Eric Blake ebl...@redhat.com Date: Wed, 16 Nov 2011 10:09:12 -0700 Subject: [PATCH] sort: clarify wording on -k syntax MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * src/sort.c (usage): Use KEYDEF instead of POS, and call out the specific OPTS that can occur in KEYDEF. Based on a report by Lars Noodén, http://bugs.gnu.org/10019 --- src/sort.c | 17 - 1 files changed, 8 insertions(+), 9 deletions(-) diff --git a/src/sort.c b/src/sort.c index 3e94a6e..236cb6a 100644 --- a/src/sort.c +++ b/src/sort.c @@ -457,8 +457,7 @@ Other options:\n\ If F is - then read names from standard input\n\ ), stdout); fputs (_(\ - -k, --key=POS1[,POS2] start a key at POS1 (origin 1), end it at POS2\n\ -(default end of line). See POS syntax below\n\ + -k, --key=KEFDEF sort via a key; KEYDEF gives location and type\n\ -m, --merge merge already sorted files; do not sort\n\ ), stdout); fputs (_(\ @@ -483,13 +482,13 @@ Other options:\n\ fputs (VERSION_OPTION_DESCRIPTION, stdout); fputs (_(\ \n\ -POS is F[.C][OPTS], where F is the field number and C the character position\n\ -in the field; both are origin 1. If neither -t nor -b is in effect, characters\ -\n\ -in a field are counted from the beginning of the preceding whitespace. OPTS is\ -\n\ -one or more single-letter ordering options, which override global ordering\n\ -options for that key. If no key is given, use the entire line as the key.\n\ +KEYDEF is F[.C][OPTS][,F[.C][OPTS]] for start and stop position, where F is a\n\ +field number and C a character position in the field; both are origin 1, and\n\ +the stop position defaults to the line's end. If neither -t nor -b is in\n\ +effect, characters in a field are counted from the beginning of the preceding\n\ +whitespace. OPTS is one or more single-letter ordering options [bdfgiMhnRrV],\n\ +which override global ordering options for that key. If no key is given, use\n\ +the entire line as the key.\n\ \n\ SIZE may be followed by the following multiplicative suffixes:\n\ ), stdout); -- 1.7.7.1 -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
bug#10019: sort options -Mn are incompatible
Eric Blake wrote: Sure. Here's the current state of things in patch format; any last objections before I push this? ... Subject: [PATCH] sort: clarify wording on -k syntax * src/sort.c (usage): Use KEYDEF instead of POS, and call out the specific OPTS that can occur in KEYDEF. Based on a report by Lars Noodén, http://bugs.gnu.org/10019 ... +KEYDEF is F[.C][OPTS][,F[.C][OPTS]] for start and stop position, where F is a\n\ +field number and C a character position in the field; both are origin 1, and\n\ +the stop position defaults to the line's end. If neither -t nor -b is in\n\ +effect, characters in a field are counted from the beginning of the preceding\n\ +whitespace. OPTS is one or more single-letter ordering options [bdfgiMhnRrV],\n\ +which override global ordering options for that key. If no key is given, use\n\ +the entire line as the key.\n\ Thanks. That reads well. Note that some tool of yours appears to have split many lines of that patch.
bug#10064: sort: sometimes segfault with certain limits (using prlimit)
For the new support of util-linux' prlimit to allow a command to be run http://article.gmane.org/gmane.linux.utilities.util-linux-ng/5039 I tried to find a useful example for the manpage. I found a nice, huge file to feed sort with - /dev/zero, and my first try was to let the command be killed after 1 CPU second: ./prlimit --cpu=1 sort -u /dev/zero Don't do that! ;-) But as I was playing around with various different limits and values, sort sometimes segfaulted: prlimit --stack=1000 --memlock=10 --rss=1000 sort -u /dev/zero Well, mostly (4/5 times) sort got correctly Killed, but a segfault smells. Similar limit values (not leading to OOM killer) behaved the same. OpenSuSE-11.4, sort from git. Have a nice day, Berny
bug#10064: sort: sometimes segfault with certain limits (using prlimit)
On 11/16/11 09:25, Bernhard Voelker wrote: prlimit --stack=1000 --memlock=10 --rss=1000 sort -u /dev/zero Well, mostly (4/5 times) sort got correctly Killed, but a segfault smells. Sorry, I don't have prlimit and don't know what it does. Can you reproduce the problem with a standard shell and ulimit? Or failing that, can you give a backtrace?
bug#10021: [PATCH id] Add error-checking on GNU
On 11/15/2011 10:09 AM, Eric Blake wrote: Still debatable. POSIX explicitly states that the condition of errno after a successful call to a standardized function is unspecified; that is, a successful geteuid() may pollute errno, but it's okay, because the user shouldn't be inspecting errno after geteuid(). It might be worth proposing a change to POSIX to require that geteuid() and friends leave errno unchanged on success (in order to allow for the GNU extension of setting errno on failure, even though POSIX did not reserve a specific value for failure); I'll pursue that course. Done: http://austingroupbugs.net/view.php?id=511 -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
bug#10019: sort options -Mn are incompatible
On 11/12/2011 06:54 AM, Eric Blake wrote: POS is F[.C][OPTS], where F is the field number and C the character position in the field; both are origin 1. If neither -t nor -b is in effect, characters in a field are counted from the beginning of the preceding whitespace. OPTS is one or more single-letter ordering options, which override global ordering options for that key. If no key is given, use the entire line as the key. In particular, -k1b,1 is different than -k1,1b, but most other OPTS can occur in either position with no change in behavior. I like [OPTS] slightly better than [ORD], given that you can have more than one (as in -k1bn,1). In fact, this thread prompted me to file a bug against POSIX, where a strict reading of the existing text says that portable clients cannot use more than one OPT simultaneously, even though all implementations that I tried support that usage. http://austingroupbugs.net/view.php?id=510 -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
bug#10019: sort options -Mn are incompatible
On 11/16/2011 10:21 AM, Jim Meyering wrote: Eric Blake wrote: Sure. Here's the current state of things in patch format; any last objections before I push this? ... Subject: [PATCH] sort: clarify wording on -k syntax * src/sort.c (usage): Use KEYDEF instead of POS, and call out the specific OPTS that can occur in KEYDEF. Based on a report by Lars Noodén, http://bugs.gnu.org/10019 ... +KEYDEF is F[.C][OPTS][,F[.C][OPTS]] for start and stop position, where F is a\n\ +field number and C a character position in the field; both are origin 1, and\n\ +the stop position defaults to the line's end. If neither -t nor -b is in\n\ +effect, characters in a field are counted from the beginning of the preceding\n\ +whitespace. OPTS is one or more single-letter ordering options [bdfgiMhnRrV],\n\ +which override global ordering options for that key. If no key is given, use\n\ +the entire line as the key.\n\ Thanks. That reads well. Pushed. Note that some tool of yours appears to have split many lines of that patch. That's what I get for pasting into a Thunderbird compose window, instead of sending as an attachment. Obviously, the patch itself is not line split that badly. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
bug#10019: sort options -Mn are incompatible
On 11/16/11 09:27, Eric Blake wrote: That's what I get for pasting into a Thunderbird compose window Here's how to shut that annoying feature off: http://kb.mozillazine.org/Plain_text_e-mail_-_Thunderbird#Flowed_format
