bug#17121: tr result is different when executed in /usr/bin

2014-03-28 Thread Benoît DUNAND-LAISIN
Thanks for your explanations.

Regards,
Benoit


2014-03-27 17:00 GMT+01:00 Pádraig Brady p...@draigbrady.com:

 tag 17121 notabug
 close 17121
 stop

 On 03/27/2014 09:43 AM, Benoît DUNAND-LAISIN wrote:
  Problem discovered in tr (GNU coreutils) 8.13 on a Ubuntu 12.04.
 
  Running those commands:
 
  cd $HOME
  echo Linux | tr [:upper:] [:lower:]
 
  will result: linux
 
  Running the same from /usr/bin:
 
  cd /usr/bin
  echo Linux | tr [:upper:] [:lower:]
 
  will result: winux
  which is obviously a bad answer.
 
  In debug mode:
 
  sh -xc echo Linux | tr [:upper:] [:lower:]
  + echo Linux
  + tr [:upper:] w
  winux

 You debugged correctly but failed to see that
 tr was getting passed the wrong options. See 'w' above.
 That's because the shell is interpreting the [...]
 You need to quote it:

 $ echo 'Linux' | tr '[:upper:]' '[:lower:]'

 thanks,
 Pádraig.

 p.s. cd without the $HOME changes to the home directory



bug#17103: regression: cp -al doesn't copy symlinks, but tries to link to them (fail)

2014-03-28 Thread Linda Walsh



Kees Cook wrote:

So, allowing a hardlink to a symlink means that symlinks owned by the
target user could be hardlinked to in /tmp. 

---
How would that be different than the user creating
a symlink in tmp?  I.e. Theoretically, they can already create
a symlink in tmp.
---

The attack gets more and
more remote, but these kind of flaws are not unheard of.


If there's a URL for to explain why this is needed, I'd
love to read more.  My background is computer science and have
have worked in security, so I'm aware of theory, but logically,
I am still not seeing the chain of events.  It seems like the
protected symlink was designed for use in a world-writeable w/
sticky bit set, so I'm not seeing the need for the extra
check on hard-link in relation to that.

It seems more like use of a blunt instrument rather
than making use of the mode bits (or DACL) on a symlink.

As far as the given reasoning for symlink control,
I've not heard of any issues related to TOU on devices/pipes
or other file system objects that couldn't be applied to files.
I.e. Do you know why they'd blanket ban everything except
files?

BTW -- you said:

Though this case of hardlink-copying a writable unowned 
tree is pretty unusual already! :)


   The business of using groups for access control is being
increasingly ignored in many system utils -- something I find
very annoying.  Maybe, with increasing use of user and group
specific ACL's, someone might realize that group access can
also be used selectively.  Too many system utils are checking
to see that they are root-user-only writeable which supersedes
a local site's security policy.



Regardless, if your system isn't at risk for such attacks, makes sense
to turn if off if it's getting in your way. :)

---
I wasn't are of the problem until just recently and I think
the hardlink part of it is 'not well considered' given the current
evidence, but I'd really like to know better what made it a problem.

At least, we are agreed on 'cp' doing the most good for the most users.
That principle seems increasingly lost amongst the legalistically
inclined (c.f. shoveling snow off the sidewalk in front of your house,
where owners were held liable if they had shoveled (i.e. took mitigating
action), but not if they didn't).  Sigh.







bug#17138: how to respect target symlinks w/cp? problem?

2014-03-28 Thread Linda Walsh

I was wanting to copy a source tree
to a target where the target had some symlink'd dirs..


/arch64/ \cp -r usr/. ../usr/.
cp: cannot overwrite non-directory `../usr/././share' with directory 
`usr/./share'

I have a setup on a bi-arch machine
where /usr/share under each 'arch' points to a common
/common/share/... I see options in the manpage for
having cp respect the SOURCE symlinks, but
see no option to have it respect symlinks in the target.

Note: If I wanted the target's symlinks to be overwritten
or ignored, I would use cp -fa that would overwrite
the symlinks (I think) and create them as directories,
but barring a, why doesn't it just follow the path?

The purpose of symlinks was to allow seamless redirection,
but now more utils seem to be ignoring that usage just
like on a security level group access is being increasingly
ignored.

tar just overwrites the symlink with the dir w/o warning...