On 03/25/2014 07:25 AM, Paul Eggert wrote:
(the second is just a code cleanup).
Oops, that 2nd patch
http://git.sv.gnu.org/cgit/coreutils.git/commit/?id=7f669b40
now produces the following check failure:
FAIL: tests/mv/i-3
==
++ initial_cwd_=/home/berny/coreutils
++ fail=0
On 03/26/2014 01:26 PM, Bernhard Voelker wrote:
On 03/25/2014 07:25 AM, Paul Eggert wrote:
(the second is just a code cleanup).
Oops, that 2nd patch
http://git.sv.gnu.org/cgit/coreutils.git/commit/?id=7f669b40
now produces the following check failure:
FAIL: tests/mv/i-3
Pádraig Brady wrote:
In general we should allow these patches a little
while for review before pushing.
Perhaps I was a bit enthusiastic here, but still, I don't know, when in
doubt I prefer an Emacs-like approach (push early and often and fix as
soon as you can) to a glibc-like approach
(1) I am using the following version of sort,
$ sort --version
sort (GNU coreutils) 5.97
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software. You may redistribute copies of it under the terms of
the GNU General Public License http://www.gnu.org/licenses/gpl.html.
There is NO
tag 17099 notabug
thanks
On 03/26/2014 07:42 AM, Prem Thoppae wrote:
include/CFixFX_Server.h
../include/CFxBaseMsg.h
include/CFXBookManager.h
I am expecting for all the ../include's to bunch up before or after all
the include's. But, the above is already in sorted order,
On 03/26/2014 03:29 PM, Paul Eggert wrote:
Pádraig Brady wrote:
In general we should allow these patches a little
while for review before pushing.
Perhaps I was a bit enthusiastic here, but still, I don't know, when in doubt
I prefer an Emacs-like approach (push early and often and fix as
have a simple test case:
as root (w /umask 002):
mkdir -p dir/{a,b}
touch dir/b/file
ln -s ../b/file dir/a/symfile
---
So now tree should look like:
tree -AFugp dir
dir
+-- [drwxrwxr-x root root] a/
| +-- [lrwxrwxrwx root root] symfile - ../b/file
+-- [drwxrwxr-x root
On 03/26/2014 06:08 PM, Linda Walsh wrote:
have a simple test case:
as root (w /umask 002):
mkdir -p dir/{a,b}
touch dir/b/file
ln -s ../b/file dir/a/symfile
---
So now tree should look like:
tree -AFugp dir
dir
+-- [drwxrwxr-x root root] a/
| +-- [lrwxrwxrwx root
Pádraig Brady wrote:
On 03/26/2014 06:08 PM, Linda Walsh wrote:
have a simple test case:
as root (w /umask 002):
mkdir -p dir/{a,b}
touch dir/b/file
ln -s ../b/file dir/a/symfile
---
So now tree should look like:
tree -AFugp dir
dir
+-- [drwxrwxr-x root root] a/
| +--
On 03/26/2014 02:21 PM, Linda Walsh wrote:
As far as I know, you could never hardlink
to a symlink. only to a file.
Wrong. Linux and Solaris have been able to hard link to symlinks for
YEARS; and POSIX 2008 standardized that ability when it added the
linkat() syscall. BSD has been
On 03/26/2014 08:21 PM, Linda Walsh wrote:
Pádraig Brady wrote:
On 03/26/2014 06:08 PM, Linda Walsh wrote:
have a simple test case:
as root (w /umask 002):
mkdir -p dir/{a,b}
touch dir/b/file
ln -s ../b/file dir/a/symfile
---
So now tree should look like:
tree -AFugp dir
dir
Eric Blake wrote:
On 03/26/2014 02:21 PM, Linda Walsh wrote:
As far as I know, you could never hardlink
to a symlink. only to a file.
Wrong.
---
How can you presume to say what I wrote
about my 'knowledge' (as far as I knew), is wrong? You
are implying that I wrote
Pádraig Brady wrote:
That is true, but I confirmed that this is caused by protected_hardlinks
Perhaps there is a blanket ban on symlinks if you're not the owner,
since the symlink could be later changed to point somewhere more sensitive?
Kees do you know if this is the case?
---
If
On 03/26/2014 02:57 PM, Linda Walsh wrote:
Furthermore, the man page says -l: hard link files instead
of copying'. AFAIK, symlinks are not files any more
than directories (or is that wrong too and they are now
considered to be 'files'?
Per the POSIX definition, symlinks, directories, FIFOS,
Linda Walsh wrote:
Any idea how this managed to be broken?
My guess is that it's SELinux. Try doing the following:
1. Create 'dir' as before.
2. As the user, run the following shell commands:
LC_ALL=C
export LC_ALL
ln dir/a/symfile dir/b
Assuming this fails, look at the output of:
Linda Walsh wrote:
I compile my own kernel.
I don't have SELinux compile in.
That's interesting. Can you try the suggested test anyway? Perhaps the
problem is not limited to SELinux.
I've managed to reproduce the problem on Fedora 20. It indeed is a
kernel thing having to do with security. Not only can 'cp' not create
hardlinks to symlinks; it also can't create hardlinks to regular files.
The problem affects all applications, e.g., 'ln'.
Not much that coreutils can do
Paul Eggert wrote:
I've managed to reproduce the problem on Fedora 20. It indeed is a
kernel thing having to do with security. Not only can 'cp' not create
hardlinks to symlinks; it also can't create hardlinks to regular files.
Actually, we've already verified that creating hardlinks
Linda Walsh wrote:
if for some reason a symlink
cannot be linked to, then the symlink should be copied (not what
the symlink is pointing to, but the actual contents of the symlink
inode -- i.e. the redirection path).
Sure, but that's asking for different functionality than what's
documented,
I fell into this problem as well about 5 weeks ago.
set the environment variable
export LC_ALL=C
sort .
and the proper collating sequence will prevail.
Regards
Leslie
Mr. Leslie Satenstein
SENT FROM MY OPEN SOURCE LINUX SYSTEM.
$ sort
On 03/27/2014 12:57 AM, Paul Eggert wrote:
Linda Walsh wrote:
if for some reason a symlink
cannot be linked to, then the symlink should be copied (not what
the symlink is pointing to, but the actual contents of the symlink
inode -- i.e. the redirection path).
Sure, but that's asking for
On 03/27/2014 02:57 AM, Pádraig Brady wrote:
I've attached a patch for illustration.
However I don't like it because it doesn't deal with,
1. fifos, device files, setuid regular files, nor,
2. relative symlinks that traverse outside the copied hierarchy.
Actually point 2 isn't specific to
Pádraig Brady wrote:
I think I see the reason for excluding symlinks here.
It's so one is able to remove a sensitive symlink and know there
are no more links to it that could be later replaced back.
Allowing that could bypass subsequent protected_symlinks checks.
---
What would a 'sensitive
Pádraig Brady wrote:
I'm not sure there is anything we should do here.
I looked at http://lwn.net/Articles/503671/ and as far as I can tell
symlinks are vulnerable to none of the attacks they mention, because
symlinks are unalterable. However, the non-symlink hardlink attacks are
a real
Pádraig Brady wrote:
On 03/27/2014 02:57 AM, Pádraig Brady wrote:
I've attached a patch for illustration.
However I don't like it because it doesn't deal with,
1. fifos, device files, setuid regular files, nor,
2. relative symlinks that traverse outside the copied hierarchy.
Actually
Paul Eggert wrote:
Pádraig Brady wrote:
I'm not sure there is anything we should do here.
I looked at http://lwn.net/Articles/503671/ and as far as I can tell
symlinks are vulnerable to none of the attacks they mention, because
symlinks are unalterable. However, the non-symlink hardlink
26 matches
Mail list logo
