[if you weren't following this thread, see the later (self-contained) part
of this message for explanation.]
On Fri, 13 Jul 2001, der.hans wrote:
> Am 12. Jul, 2001 schwäzte Faheem Mitha so:
>
> > Agreed, but I do... :-) I think the problem may be that the non-existent
> > user owning the directory is confusing the permission system. Can't think
>
> Don't matter to root. System doesn't look to see if the user exists ( guess
> that could be added to pam, but AFAIK it hasn't been at this point ).
Right, this was not the problem, though it is still a little strange. (See
comments at end of message).
> ugo = user group other
>
> First char tells about the file. d is for directory, - means plain file.
> There are a couple of other valid types.
>
> The next three are for who owns the file, then group, then finally other.
>
> if owner matches, then the first three are in effect.
> elsif the user is in the same group as the file the second trilogy is in
> effect.
> else the third is in effect.
>
> If the owner doesn't exist, then no one matches that part, but the owner
> not existing is irrelevant.
>
> Oh, BTW, there's another check. If you are UID 0, called root, then we skip
> those little permission checks and just let you mangle things :).
Yes, but not always. I am still not clear on the rules for this.
> I have seen, however, that removing all perms can also prevent root from
> changing a file. Technically, that shouldn't happen.
>
> > The output of find / -user 1000 (in total) is
> >
> > Chrestomanci:/# find / -user 1000
> > /mnt/suse/home/faheem/debian/pgp4pine-1.75-6
>
> OK, if this is where your home dir is, especially if it's listed
> as /home/faheem in /etc/passwd, but /home/faheem shows up as
> /mnt/suse/home/faheem due to the magic of soft links, then "usermod -u"
> probably won't change perms in your home dir. In other words, it probably
> ignores soft links.
On the suggestion of Hendrik Sattler in reply to an earlier post of my to
debian users, I changed /etc/passwd to have /mnt/suse/home/faheem to be my
home directory.
> Also, I presume you've checked, but that partition is mounted read/write not
> read-only, right? rw instead of ro in mount output.
I've got it mounted as
/dev/hdb3 /mnt/suse ext2 defaults,user 0
and I am able to read, write.
I've come to the conclusion that the problem I was having (summary, I
mounted my home directory from my old SuSE partition,
/mnt/suse/home/faheem and was unable to run apt-get source -b within it as
root) was due to permissions problem with the directory. If I mount a home
directory on /home/faheem for example, then I can run apt-get source -b
and everything is fine. The permissions for my current home directory
(/mnt/suse/home/faheem) are
drwxr-xr-x 21 root root /
drwxr-xr-x 3 root root mnt
drwxr-xr-x 23 root root suse
drwxr-xr-x 5 root root home
drwxr-xr-x 106 faheem users faheem
In contrast, my old /home/faheem has the following permissions
drwxr-xr-x 21 root root /
drwxrwsr-x 4 root staff home
drwxr-sr-x 20 faheem users faheem
In /mnt/suse/home/faheem I cannot run apt-get source -b either as user
(fakerooted) or root. In /home/faheem I can do both. Can anyone explain
why? The most obvious difference is that the set uid/gid bit is on, but I
don't see how that accounts for anything.
Incidentally, the permissions that dpkg-source (I think it is) gives the
unpacked source directory when it is called by apt-get as root to unpack
the sources is extremely odd. For pgp4pine it gives the permission 1000,
1000 (owner, group), for GNU hello it gives (100, 100), for slrn it gives
(500, 500). These permissions seem constant in that they are the same for
the same package no matter what user I run apt-get source -b as. In some
cases these numbers correspond to actual users/groups, in other cases they
don't. Is there some reason for why these are what they are, and why they
are different for each package? I can't see how anything I am doing is
making this happen. Can anyone reproduce this behaviour? NOTE THIS ONLY
HAPPENS AS ROOT.
Sincerely, Faheem Mitha.
