FAQ
Greetings,
i had a following problem, which on one side i have already solved, but
on other side i don't thing it should behave this way and wish somebody to
tell if it is feature or bug ;-)

[root@machine home]# chown user user/
[root@machine home]# ls -ld /home/user
drwxr-xr-x 66 user staff 4096 /home/user
[root@machine home]# chgrp -R staff user/
[root@machine home]# ls -ld user/
drwxr-xr-x 66 root staff 4096 user/
^^^^^^

I've been working on it hole afternoon, playing with user permissions,
moving home directories to others, debugging selinux and other things,
but at last, it was caused by

[root@machine home]# ls -la user/.openoffice/user/work
lrwxrwxrwx 1 root root 13 Aug 28 14:35 user/.openoffice/user/work -> /home/user

When i remove this symlink, everything works fine.

I tried this on CentOS 4.4 and 4.5 with
coreutils-5.2.1-31.4 and
coreutils-5.2.1-31.6
and both are doing this. CentOS 5 with
coreutils-5.97-12.1.el5
is already fine.

I've been searching through coreutils gnu.org archives, but found
nothing (maybe i'm not so experienced seeker ;-))

Thanks
-------------------------------------------------------------------------------
Tom?? Ruprich ruprich@uikt.mendelu.cz
DCD IICT MUAF Brno
tel.: +420 545 132 885, +420 602 127 744
-------------------------------------------------------------------------------

Search Discussions

  • Tomas Ruprich at Aug 30, 2007 at 5:39 pm

    Thu, Aug 30, 2007 ve 06:05:49PM +0200, Tomas Ruprich napsal:
    Greetings,
    i had a following problem, which on one side i have already solved, but
    on other side i don't thing it should behave this way and wish somebody to
    tell if it is feature or bug ;-)

    [root@machine home]# chown user user/
    [root@machine home]# ls -ld /home/user
    drwxr-xr-x 66 user staff 4096 /home/user
    [root@machine home]# chgrp -R staff user/
    [root@machine home]# ls -ld user/
    drwxr-xr-x 66 root staff 4096 user/
    ^^^^^^
    just to be accurate, this doesn't happen when using --no-dereference and it is not
    changing permissions to root, but to user who is the owner of the link, so:

    [root@machine home]# ls -la user/.openoffice/user/work
    lrwxrwxrwx 1 nobody root 13 Aug 28 14:35 user/.openoffice/user/work -> /home/user
    [root@machine home]# ls -ld /home/user
    drwxr-xr-x 66 user staff 4096 /home/user
    [root@machine home]# chgrp -R staff user/
    [root@machine home]# ls -ld user/
    drwxr-xr-x 66 nobody staff 4096 user/

    -------------------------------------------------------------------------------
    Tom?? Ruprich ruprich@uikt.mendelu.cz
    DCD IICT MUAF Brno
    tel.: +420 545 132 885, +420 602 127 744
    -------------------------------------------------------------------------------
  • William L. Maltby at Sep 2, 2007 at 3:21 pm

    On Thu, 2007-08-30 at 19:39 +0200, Tomas Ruprich wrote:
    Thu, Aug 30, 2007 ve 06:05:49PM +0200, Tomas Ruprich napsal:
    Greetings,
    i had a following problem, which on one side i have already solved, but
    on other side i don't thing it should behave this way and wish somebody to
    tell if it is feature or bug ;-)

    [root@machine home]# chown user user/
    [root@machine home]# ls -ld /home/user
    drwxr-xr-x 66 user staff 4096 /home/user
    [root@machine home]# chgrp -R staff user/
    [root@machine home]# ls -ld user/
    drwxr-xr-x 66 root staff 4096 user/
    ^^^^^^
    just to be accurate, this doesn't happen when using --no-dereference and it is not
    changing permissions to root, but to user who is the owner of the link, so:

    [root@machine home]# ls -la user/.openoffice/user/work
    lrwxrwxrwx 1 nobody root 13 Aug 28 14:35 user/.openoffice/user/work -> /home/user
    [root@machine home]# ls -ld /home/user
    drwxr-xr-x 66 user staff 4096 /home/user
    [root@machine home]# chgrp -R staff user/
    [root@machine home]# ls -ld user/
    drwxr-xr-x 66 nobody staff 4096 user/
    <snip sig stuff>
    ISTM it's a bug and should be reported on both CentOS and RH tracking
    systems. Two errors are apparent. One may be difficult to correct.

    As you originally discovered, the user ID is being change during
    execution of the command to change a group. And it is using the ID from
    the symbolic link owner, as you later noticed.

    The 2nd bug is a recursion into the original directory via the symbolic
    link when dereference is not suppressed. IMO, recursion should not
    occur, but I know from a programming background that it takes a little
    foresight, thought and intense effort to avoid this sort of trap.

    As an afterthought, how valid is it to have user control files that are
    supposed to be contained in an "invisible" directory in the user's
    $HOME? This presents a "non-standard" structure that offers increased
    opportunities for mishaps of various types.

    --
    Bill
  • Tomas Ruprich at Sep 4, 2007 at 11:16 am
    Thanks for your reply and your time,
    i've reported it to centos bug tracking system. I will try it also on
    RHEL and if it occurs, i'll sent it also to the RH.
    ISTM it's a bug and should be reported on both CentOS and RH tracking
    systems. Two errors are apparent. One may be difficult to correct.

    As you originally discovered, the user ID is being change during
    execution of the command to change a group. And it is using the ID from
    the symbolic link owner, as you later noticed.

    The 2nd bug is a recursion into the original directory via the symbolic
    link when dereference is not suppressed. IMO, recursion should not
    occur, but I know from a programming background that it takes a little
    foresight, thought and intense effort to avoid this sort of trap.
    I think, that dereferrence should occure (at least for my coreutils
    version); man chgrp:
    --dereference
    affect the referent of each symbolic link, rather than the symbolic
    link itself (this is the default)
    As an afterthought, how valid is it to have user control files that are
    supposed to be contained in an "invisible" directory in the user's
    $HOME? This presents a "non-standard" structure that offers increased
    opportunities for mishaps of various types.

    --
    Bill
    Well, that's another point, but that's not my job here :( I realized
    this behavior on shared home directories server. These homes are
    used by Win domain in classrooms, on terminal services, etc. It's not my
    business to control, if some users (or local administrators) create symlink
    to their home directory... But maybe i should write some little audit
    scrip, which would search for these...

    thanks,
    Tomas
  • William L. Maltby at Sep 17, 2007 at 11:16 pm

    On Tue, 2007-09-04 at 13:16 +0200, Tomas Ruprich wrote:
    Thanks for your reply and your time,
    i've reported it to centos bug tracking system. I will try it also on
    RHEL and if it occurs, i'll sent it also to the RH.
    Good. If and when they close it, will you post in this thread so folks
    know the result?
    ISTM it's a bug and should be reported on both CentOS and RH tracking
    systems. Two errors are apparent. One may be difficult to correct.

    As you originally discovered, the user ID is being change during
    execution of the command to change a group. And it is using the ID from
    the symbolic link owner, as you later noticed.

    The 2nd bug is a recursion into the original directory via the symbolic
    link when dereference is not suppressed. IMO, recursion should not
    occur, but I know from a programming background that it takes a little
    foresight, thought and intense effort to avoid this sort of trap.
    I think, that dereferrence should occure (at least for my coreutils
    version); man chgrp:
    --dereference
    affect the referent of each symbolic link, rather than the symbolic
    link itself (this is the default)
    I don't have an issue with dereference. My issue is is the recursion
    into the directories that the symbolic link points to. This is a well
    known potential problem when symbolic links point to places that have
    symbolic links that (eventually) lead to the original symbolic link
    again. Some packages (tar and find, IIRC and maybe some others) try to
    avoid this trap in various ways.

    IMO, all utilities that normally recurse in an environment wherein
    looping via such mechanisms as symbolic links is possible should have
    some basic checks trying to prevent eternal loops from occurring. I do
    think the recursion, as reported in your OP, is a bug in that the
    utility has not (apparently) made an attempt to prevent an interminable
    loop.

    But, that's my opinion from the days when we developers were expected to
    do rigorous design and testing, rather than leaving it (intentionally)
    to our users to suffer and report.
    <snip>
    --
    Bill

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcentos @
categoriescentos
postedAug 30, '07 at 4:05p
activeSep 17, '07 at 11:16p
posts5
users2
websitecentos.org
irc#centos

People

Translate

site design / logo © 2022 Grokbase