[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