[Buildd-tools-devel] Bug#476332: Bug#476332: schroot: Fails mysteriously when /etc/schroot/schroot.conf is a symlink

Roger Leigh rleigh at whinlatter.ukfsn.org
Wed Apr 16 22:06:38 UTC 2008


On Tue, Apr 15, 2008 at 06:41:31PM -0400, Timothy G Abbott wrote:
> Package: schroot
> Version: 1.1.6-1
> Severity: normal
> 
> When I try to use schroot on a system where /etc/schroot/schroot.conf is a 
> symbolic link to another file (I've triple-checked that it's a regular 
> file and not another symlink), I get the following strange error:
> 
> $ schroot -pc athena
> E: /etc/schroot/schroot.conf: Failed to open file: Too many levels of symbolic links
> 
> There's only one symbolic link involved, and the normal limit for 
> recursive symbolic links on linux is much higher than that.

The standard errors (from the source code) are:

FILE_NOTREG, "File is not a regular file"
FILE_OPEN,   "Failed to open file"
FILE_OWNER,  "File is not owned by user root"
FILE_PERMS,  "File has write permissions for others"))

Due to running setuid-root, I do some extra checks to ensure that the
system can't be compromised if the permissions are wrong.  One
additional step we take is here:

  // stat filename (in case it's a pipe and open(2) blocks)
  stat file_status1(file);
  if (file_status1.uid() != 0)
    throw error(file, FILE_OWNER);
  if (file_status1.check_mode(stat::PERM_OTHER_WRITE))
    throw error(file, FILE_PERMS);
  if (!file_status1.is_regular())
    throw error(file, FILE_NOTREG);

  /* Use a UNIX fd, for security (no races) */
  int fd = open(file.c_str(), O_RDONLY|O_NOFOLLOW);
  if (fd < 0)
    throw error(file, FILE_OPEN, strerror(errno));

Your errror is from the last line.  We deliberately instructed open(2)
to not follow symbolic links with the O_NOFOLLOW, which is why you get
the rather cryptic error about "too many levels of symbolic links"--
one level or greater is too much in this case.

I chose to do this for security reasons, but this could be changed by
removing the O_NOFOLLOW.  I would, however, need to be convinced that
this was no less secure than with the O_NOFOLLOW before changing this
--I don't want to unintentionally introduce a security exploit, so I
chose the convervative option originally.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.





More information about the Buildd-tools-devel mailing list