su operation on RHES V5.2
A few days ago, I sent an e-mail regarding the behaviour of su - usernameas seen in Redhat enterprise edition v5 update 2. Briefly if you su - username and that user name is an ldap user, no action appears to be taken. The log shows the user was accessed then immediately disconnected. We have since found that if the nscd daemon is running, the su - username command works for ldap users. But as soon as nscd is stopped, the command again fails to take any action. We also reported that if su is run with strace, the command also succeeds. Can you tell us if this is expected behaviour ? Al Licause HP Services Unix Network Team ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: coreutils 6.12 test-suite failure
On Friday 13 June 2008 04:29:17 pm Jim Meyering wrote: > Jarod Wilson <[EMAIL PROTECTED]> wrote: > > Hey there, > > > > Trying to reproduce a problem we (Red Hat) are seeing when building > > coreutils 6.12 in our build system[*], and I ran into a slightly > > different (and 100% reproduceable so far) test-suite failure. Log file > > attached. Build is done on a system with a 2.6.18-based kernel (RHEL5.2), > > building against 2.6.26-ish bits in a chrooted environment. > > > > [*] https://bugzilla.redhat.com/show_bug.cgi?id=442352 > > Hi Jarod, > > Thanks for reporting that. > First off, those failures are all in root-only tests. Finally got around to running a new build with your follow-up patch. > FAIL: misc/runcon-no-reorder.log (exit: 1) > == > + runcon root:system_r:unconfined_t:s0-s0:c0.c1023 true -j > + diff -u out exp > ... > -runcon: invalid context: root:system_r:unconfined_t:s0-s0:c0.c1023: No > such file or directory +runcon: runcon may be used only on a SELinux kernel > > While I know the low-level cause (an strace from Ondrej Vasik > showed that /selinux/context doesn't exist in the chroot), > up to now, I hadn't worried about this failure, because I > thought it was specific to an (end-of-life) FC6 system. As expected, this one still triggers. > FAIL: cp/cp-a-selinux.log (exit: 1) > === > ... > + mkdir mnt > + mkfs -t ext2 -F blob > mkfs.ext2: No such file or directory > + framework_failure > + error_ 'failure in testing framework' > > I have already prepared the tiny patch that will make this > failure skip the test rather than fail. This one is indeed skipped. > FAIL: cp/preserve-gid.log (exit: 1) > === > ... > + chown +0:+0 a0 > + create b0 1000 1000 > + echo b0 > + chown +1000:+1000 b0 > + create b1 1000 1001 > + echo b1 > + chown +1000:+1001 b1 > + create c0 0 1000 > + echo c0 > + chown +0:+1000 c0 > + create c1 0 1001 > + echo c1 > + chown +0:+1001 c1 > + t0 a0 0 0 cp > + f=a0 > + shift > + u=0 > + shift > + g=0 > + shift > + rm -f b > + cp a0 b > ++ stat -c '%u %g' b > + s='0 103' > + test 'x0 103' '!=' 'x0 0' > + test 'x0 103' = 'x0 0' > + echo './cp/preserve-gid: cp a0 b: 0 0 != 0 103' > ./cp/preserve-gid: cp a0 b: 0 0 != 0 103 > + exit 1 > > This one was trickier. I think it must be the case that > root's primary group is 103. The test requires that it be 0. > Can you confirm? (i.e., run id -g -- or better, id -a to get all of them) > I'll either adapt the test or make it skip in that case. Ah, here we go... In this case, I'm doing a build in a mock chroot, as the user 'mockbuild', who (within the chroot) has a uid of 0, gid of 101: mockbuild::0:101::/builddir:/bin/bash Nb: for this run, the log actually says: ... ++ stat -c '%u %g' b + s='0 101' + test 'x0 101' '!=' 'x0 0' + test 'x0 101' = 'x0 0' + echo './cp/preserve-gid: cp a0 b: 0 0 != 0 101' ./cp/preserve-gid: cp a0 b: 0 0 != 0 101 + exit 1 > FAIL: rm/fail-2eperm.log (exit: 1) > == > ... > ++ setuidgid nobody env > PATH=/builddir/build/BUILD/coreutils-6.12/src:/usr/lib64/ccache:/usr/kerber >os/sbin:/usr/kerberos/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbi >n:/usr/bin:/root/bin rm --version ++ sed -n '1s/.* //p' > + rm_version=6.10 > + case $rm_version in > + echo './rm/fail-2eperm: cannot access just-built rm as user nobody' > ./rm/fail-2eperm: cannot access just-built rm as user nobody > + fail=1 > > FYI, this failure would have been avoided if the test had > been run as suggested in README [...] > Nonetheless, reports like this are common enough that I'll > make it so this test is skipped too, when this happens. The tests are run in an entirely automated fashion as part of the rpm build process, never looked at the README... :) But yeah, this one doesn't trigger anymore. > Patch for two of those coming right up. > I'll wait to hear back from you before addressing preserve-gid, > and I'm not yet sure what to do about runcon-no-reorder. HTH, -- Jarod Wilson [EMAIL PROTECTED] ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Feature request - base64 Filename Safe Alphabet
Simon Josefsson wrote:
> Christopher Kerr <[EMAIL PROTECTED]> writes:
>
>> After being burned by using `head -c6 /dev/urandom | base64` as part of a
>> directory name, I realised that it would be useful if base64 had an option
>> to
>> generate URL and Filename safe encodings, as specified in RFC 3548 section 4.
>>
>> This would make
>> cat FILE | base64 --filename-safe
>> equivalent to
>> cat FILE | base64 | tr '+/' '-_'
>> using the current coreutils tools.
>
> I think --filename-safe is a good idea. The documentation should
> discuss the potential for generating files starting with '-' or '--'.
> Patching gnulib's base64.c to support an arbitrary alphabet seems messy.
> Patches welcome though.
Hi Simon,
I thought I'd take a stab at this and see where it goes.
What I've done is exposed an additional set of functions, *_a, which
take an arbitrary alphabet as an extra parameter. Each historical
function now calls one of these with the 'main' alphabet. I then added
a parallel set of functions, *_filesafe, which call the *_a functions
with the alphabet described above.
It is a little messy, I think, because the large hand-initialized
data-structures are duplicated. The messiness could be reduced by
having base64 just expose the *_a interface for using an arbitrary
alphabet, and adding a second module (base64_filesafe?) that provided
that specific alternate (with all its attendant bulk).
In any case, as with my previous patches I've tried not to alter the
behavior of any already existing functions.
I've also attached a small patch against coreutils' base64 utility that
provides the desired behavior. There are no documentation/tests/etc
yet. It's only for demonstration purposes.
How does this look to you?
Thanks,
Bo
>From fcb70d9fdd1c7979f0e3ee499a48248fd771 Mon Sep 17 00:00:00 2001
From: Bo Borgerson <[EMAIL PROTECTED]>
Date: Wed, 18 Jun 2008 19:16:01 -0400
Subject: [PATCH] base64: Provide an interface for alphabet configurationi and a filesafe alphabet.
* lib/base64.c (base64_encode_a): Was base64_encode. Takes an alphabet.
(base64_encode_alloc_a): Was base64_encode_alloc. Takes an alphabet.
(isbase64_a): Was isbase64. Takes an alphabet.
(isbase64 isbase64_filesafe): Call isbase64_a with appropriate alphabet.
(decode_4): Takes an alphabet.
(base64_decode_ctx_a): Was base64_decode_ctx. Takes an alphabet.
(base64_decode_alloc_ctx_a): Was base64_decode_alloc_ctx. Takes an alphabet.
* lib/base64.h (base64_encode): Now a wrapper around base64_encode_a.
(base64_encode_filesafe): Likewise.
(base64_encode_alloc): Now a wrapper around base64_encode_alloc_a.
(base64_encode_alloc_filesafe): Likewise.
(base64_decode_ctx): Now a wrapper around base64_decode_ctx_a.
(base64_decode_ctx_filesafe): Likewise.
(base64_decode): Likewise.
(base64_decode_alloc_ctx): Now a wrapper around base64_decode_alloc_ctx_a.
(base64_decode_alloc_ctx_filesafe): Likewise.
(base64_decode_alloc): Likewise.
Signed-off-by: Bo Borgerson <[EMAIL PROTECTED]>
---
lib/base64.c | 327 ++---
lib/base64.h | 54 --
2 files changed, 287 insertions(+), 94 deletions(-)
diff --git a/lib/base64.c b/lib/base64.c
index 8aff430..01baa62 100644
--- a/lib/base64.c
+++ b/lib/base64.c
@@ -61,17 +61,22 @@ to_uchar (char ch)
return ch;
}
+const char b64str_main[64] =
+ "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/";
+
+const char b64str_filesafe[64] =
+ "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-_";
+
+
/* Base64 encode IN array of size INLEN into OUT array of size OUTLEN.
If OUTLEN is less than BASE64_LENGTH(INLEN), write as many bytes as
possible. If OUTLEN is larger than BASE64_LENGTH(INLEN), also zero
terminate the output buffer. */
void
-base64_encode (const char *restrict in, size_t inlen,
- char *restrict out, size_t outlen)
+base64_encode_a (const char *restrict in, size_t inlen,
+ char *restrict out, size_t outlen,
+ const char *b64str)
{
- static const char b64str[64] =
-"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/";
-
while (inlen && outlen)
{
*out++ = b64str[(to_uchar (in[0]) >> 2) & 0x3f];
@@ -113,7 +118,8 @@ base64_encode (const char *restrict in, size_t inlen,
indicates length of the requested memory block, i.e.,
BASE64_LENGTH(inlen) + 1. */
size_t
-base64_encode_alloc (const char *in, size_t inlen, char **out)
+base64_encode_alloc_a (const char *in, size_t inlen, char **out,
+ const char *b64str)
{
size_t outlen = 1 + BASE64_LENGTH (inlen);
@@ -153,7 +159,7 @@ base64_encode_alloc (const char *in, size_t inlen, char **out)
IBM C V6 for AIX mishandles "#define B64(x) ...'x'...", so use "_"
as the formal parameter rather than "x". */
-#define B64(_) \
+#define B64M(_) \
((_) == 'A' ? 0\
: (_) == 'B' ? 1\
: (_) == 'C' ? 2\
@@ -220,71 +226,206 @@ base64_encode_alloc (const char *in, size_t
Re: [coreutils] Bug: ls --tabsize=4
On Mon, May 26, 2008 at 4:33 AM, James Youngman <[EMAIL PROTECTED]> wrote: [rearranged] > On Mon, May 26, 2008 at 8:37 AM, Philip Ganchev <[EMAIL PROTECTED]> wrote: >> So I think the manual ought to mention that ls outputs tab characters, >> that those tab characters may be displayed at various tab widths by >> the terminal (or terminal emulator), and that therefore ls needs to >> know where the tab stops are in the terminal. A patch file with the suggested text is attached. The option description reads: -T --tabsize=COLS assume tab stops at each COLS instead of 8 positions. That is, the terminal renders tab characters so that they end at each COLS positions. And the Description section includes: If output is to a terminal, by default ls outputs tabs between file names on each line of output. I am trying to understand the current design and its rationale. Sorry if my ignorant questions are annoying. Why does ls need the tab stop positions - to output newlines so that no file name is wrapped on two lines? Isn't there a way to tell the terminal not to break a string when wrapping? > Tab sizes are a property of the terminal, about which one informs the > system in order to make text output appear correct. Can't ls obtain the tab stop positions automatically (from the terminal?), without needing the user to supply it? >> Why does ls produce tab characters instead of spaces? > > I don't know. But the documentation does explain how to turn that off. Sorry, I meant produce spaces to *tabulate* the output. That involves counting how many spaces need to be printed between items so that items on different lines align in the same columns. I don't see how to do that from the manual. [...] >> And, she may prefer different tab sizes for different programs. > > IMHO then she is doomed to a certain background level of frustration. > Tab sizes are a property of the terminal, about which one informs the > system in order to make text output appear correct. Trying to do > that whole thing backwards (i.e. telling different programs different > things about the properties of the terminal they all use) is likely > not to work optimally. If every program tabulated using spaces instead of tabs, then one parameter *inside the program* would be enough to change the appearance of the output. And the output would look correct in any terminal. The formatting could be done by a library which every program could use. --- 6.13/ls.1 2008-06-19 00:49:17.0 -0400 +++ 6.12/ls.1 2008-06-19 00:19:36.0 -0400 @@ -10,8 +10,6 @@ .PP List information about the FILEs (the current directory by default). Sort entries alphabetically if none of \fB\-cftuvSUX\fR nor \fB\-\-sort\fR. -If output is to a terminal, by default ls outputs tabs between file names on -each line of output. .PP Mandatory arguments to long options are mandatory for short options too. .TP @@ -186,9 +184,7 @@ sort by modification time .TP \fB\-T\fR, \fB\-\-tabsize\fR=\fICOLS\fR -assume tab stops at each COLS instead of 8 positions. -That is, the terminal renders tab characters so that -they end at each COLS positions. +assume tab stops at each COLS instead of 8 .TP \fB\-u\fR with \fB\-lt\fR: sort by, and show, access time ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [coreutils] Bug: ls --tabsize=4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Philip Ganchev on 6/18/2008 10:58 PM: | | A patch file with the suggested text is attached. The option description reads: Thanks for the attempted patch. For now, I haven't looked at it, other than to note that ls.1 is autogenerated from 'ls --help' output, and you got your patch reversed (you want to use 'diff old new', not 'diff new old'). Would you mind trying again by patching the usage() function in src/ls.c instead? The file HACKING in coreutils.git describes how to submit nicer patches. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkhZ66wACgkQ84KuGfSFAYCMcwCfUmGODSmize5ndndDDfgYKfPS Kr4An0k+HD3y++Kl1Hv+zqQ2gw9XYXxq =eCfK -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
