Bug 5458 - usermod -u follows symlinks indefinitely
usermod -u follows symlinks indefinitely
Product: Red Hat Linux
Classification: Retired
Component: shadow-utils (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Cristian Gafton
: Security
Depends On:
  Show dependency treegraph
Reported: 1999-09-30 14:39 EDT by jlewis
Modified: 2008-05-01 11:37 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2000-02-16 10:47:52 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description jlewis 1999-09-30 14:39:30 EDT
While synchronizing uids for my accounts on several of my
systems, I noticed an issue with usermod from
shadow-utils-980403 (included with both Red Hat 5.2 and 6.0)
on both Red Hat 5.2 and 6.0 systems.  usermod -u 500
jlewis will try to chown /home/jlewis such that files owned
by jlewis's old uid become owned by jlewis's new uid.  The
problem is that usermod follows symlinks.  I issued the
command, and thought it odd that it should be taking so
long, so I straced it to see what was going on.

I saw lots of lines like:

clipped...this went on to nearly fill my xterm]

/home/jlewis/root is a symlink to /.

There are 2 problems here.  First is that because chown_tree
is recursive and follows symlinks, it can end up eating
lots of time and disk i/o as it recursively loops stat'ing
files in an infinite loop (likely until/unless usermod
crashes) as well as traversing large portions of the
mounted filesystems that probably should not have been. This
could maybe be fixed by changing (in libmisc/chowndir.c):

                if (S_ISDIR(sb.st_mode)) {

                         * Do the entire subdirectory.


         if (S_ISDIR(sb.st_mode) && !(S_ISLNK(sb.st_mode)) {

                         * Do the entire subdirectory.

and the chown a few lines down would likely need to become
lchown, so chown can't follow the symlink.

The second problem (and I'm not saying it's likely to
happen...just a theoretical problem) is that the stat to see
who owns the file is done, and then a few lines of code
later, the chown is done with the assumption the file being
chown'd is still the file that was stat'd.

If the system can be slowed enough, and if the user can
cause programs to be executed at the right time, it may be
possible to steal files by playing with symlinks.

Since usermod -u is probably not used anywhere with any
frequency or regularity, this second issue probably isn't an
urgent one, but it doesn't look very secure.  The first
issue pretty much breaks usermod -u if appropriate symlinks
are encountered.

I've only tested this on Red Hat 5.2 and 6.0 for i386.  It's
likely to affect other versions and architectures.

Since this is a shadow-suite problem, I've also notified the
Shadow mailing list at shadow@suse.com and
Comment 1 Bernhard Rosenkraenzer 2000-02-16 10:47:59 EST
Thanks, fixed.

Note You need to log in before you can comment on or make changes to this bug.