chown, but no lchown 
Author Message
 chown, but no lchown

Hello,

I need access to the lchown() system call on about three different unix platforms.  The source code appears to check for the existence of such a system call, but how do I go about using it?

thanks...

--jason

--

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jason Brooks
System / Network Administrator
Wind River Systems



Sun, 16 May 2004 23:24:18 GMT  
 chown, but no lchown

  JB> I need access to the lchown() system call on about three different
  JB> unix platforms.  The source code appears to check for the
  JB> existence of such a system call, but how do I go about using it?

why do you need to call lchown? it is almost a useless call. the owner
(or anyone with write permission) of the directory it is in can delete
it and recreate it. the ownership of a symlink never affects who can use
it so changing it means little.

uri

--

-- Stem is an Open Source Network Development Toolkit and Application Suite -
----- Stem and Perl Development, Systems Architecture, Design and Coding ----
Search or Offer Perl Jobs  ----------------------------  http://jobs.perl.org



Sun, 16 May 2004 23:43:40 GMT  
 chown, but no lchown
[Posted and mailed]



Quote:
> Hello,

> I need access to the lchown() system call on about three different unix platforms.  The source code appears to check for the existence of such a system call, but how do I go about using it?

lchown(2) is what happens when chown(perl) gets called on some platforms.

If you need to get a hold of specific system calls though, use XS or
the syscall facility to call it directly.

--
    Clinton A. Pierce            Teach Yourself Perl in 24 Hours  *and*

"If you rush a Miracle Man,     for details, see http://geeksalad.org    
        you get rotten Miracles." --Miracle Max, The Princess Bride



Mon, 17 May 2004 03:20:25 GMT  
 chown, but no lchown
On Thu, 29 Nov 2001 02:20:25 GMT,

Quote:
> [Posted and mailed]



>> Hello,

>> I need access to the lchown() system call on about three different
>> unix platforms.  The source code appears to check for the existence
>> of such a system call, but how do I go about using it?

> lchown(2) is what happens when chown(perl) gets called on some platforms.

Are you sure? Am I missing something?

[lines wrapped for post]

$ pwd
/spare/SRC/perl-5.6.1
$ find . -name \*.h -o -name \*.c | xargs grep -i lchown
./doio.c:XXX Should we make lchown() directly available from perl?
./doio.c:For now, we'll let Configure test for HAS_LCHOWN, but do
./vos/config.alpha.h:/* HAS_LCHOWN:
./vos/config.alpha.h: * This symbol, if defined, indicates that the
    lchown routine is
./vos/config.alpha.h:/*#define HAS_LCHOWN               /**/
./vos/config.ga.h:/* HAS_LCHOWN:
./vos/config.ga.h: *    This symbol, if defined, indicates that the
    lchown routine is
./vos/config.ga.h:/*#define HAS_LCHOWN          /**/

Inspection of other files leads me to believe that Configure does test
for lchown and appropriate configuration variables get set, but that
nothing really happens anywhere to act on this. There's a note in
doio.c, which has been there for a while, that leads me to
believe that the tests in Configure were put there specifically
for a possible future extension that would make lchown available
in Perl:

/*
XXX Should we make lchown() directly available from perl?
For now, we'll let Configure test for HAS_LCHOWN, but do
nothing in the core.
    --AD  5/1998
*/

Martien
--
                                |
Martien Verbruggen              |
Trading Post Australia Pty Ltd  | What's another word for Thesaurus?
                                |



Mon, 17 May 2004 03:34:09 GMT  
 chown, but no lchown


Quote:

>  JB> I need access to the lchown() system call on about three different
>  JB> unix platforms.  The source code appears to check for the
>  JB> existence of such a system call, but how do I go about using it?

>why do you need to call lchown? it is almost a useless call. the owner
>(or anyone with write permission) of the directory it is in can delete
>it and recreate it. the ownership of a symlink never affects who can use
>it so changing it means little.

But it can affect the user's disk quota.

Each symlink counts against the UID's inode limit.  Symlinks with
target names longer than 59 bytes don't fit inside the inode, causing
a disk block to be allocated and charged against the block quota.
        -Joe

--
See http://www.inwap.com/ for PDP-10 and "ReBoot" pages.



Mon, 17 May 2004 11:04:50 GMT  
 chown, but no lchown
Hello Uri,

First, thank you for replying so quickly.

I am changing the uids and gids of all of my files on all of my systems.  This crosses about 15 different machines running solaris 2.x, freebsd, linux, and hp-ux.  I also am using clearcase so the targets may not actually be available outside of a clearcase view, and chown chokes on there being no target.  Since the current chown call dereferences a symlink and changes the target's uid/gid, this could be disastrous if the wrong uid is applied to a target file.  

Alternately, running in a shell script using the "chown" program also has problems.  These problems start with filenames having spaces, and move up to filenames having shell metacharacters.

Now while I can get around this, (and will), it begs the question since the source configuration checks if the lchown() call exists.  :)

Oh, I just re-read your response.  you are correct about the symlink's permissions not affecting who can access files.  I expect to be getting a lot of queries about "why isn't this symlink owned by me".  Thus, I am really working to reduce the "pita" factor (pain in the a__).

--jason

On Wed, 28 Nov 2001 22:43:40 GMT

Quote:


>   JB> I need access to the lchown() system call on about three different
>   JB> unix platforms.  The source code appears to check for the
>   JB> existence of such a system call, but how do I go about using it?

> why do you need to call lchown? it is almost a useless call. the owner
> (or anyone with write permission) of the directory it is in can delete
> it and recreate it. the ownership of a symlink never affects who can use
> it so changing it means little.

> uri

> --

> -- Stem is an Open Source Network Development Toolkit and Application Suite -
> ----- Stem and Perl Development, Systems Architecture, Design and Coding ----
> Search or Offer Perl Jobs  ----------------------------  http://jobs.perl.org

--

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jason Brooks
System / Network Administrator
Wind River Systems



Mon, 17 May 2004 01:09:01 GMT  
 chown, but no lchown
[Posted and mailed]



Quote:
>> lchown(2) is what happens when chown(perl) gets called on some platforms.

> Are you sure? Am I missing something?

You may be right.  When I looked at this a month ago, I could've sworn
that I managed to follow lchown(2) all the way into the core.  Perhaps
what I found (and misremembered) is the varying behavior of chown(2)
through Linux's revision history.

Original advice still holds: if you want a specific system call for
sure, use syscall or XS.

--
    Clinton A. Pierce            Teach Yourself Perl in 24 Hours  *and*

"If you rush a Miracle Man,     for details, see http://geeksalad.org    
        you get rotten Miracles." --Miracle Max, The Princess Bride



Mon, 17 May 2004 13:53:55 GMT  
 chown, but no lchown
[Please put your reply after the suitably trimmed text you reply to.
It is the convention in this newsgroup, and Usenet in general]

On Wed, 28 Nov 2001 16:09:01 -0800,

Quote:
> On Wed, 28 Nov 2001 22:43:40 GMT


>>   JB> I need access to the lchown() system call on about three different
>>   JB> unix platforms.  The source code appears to check for the
>>   JB> existence of such a system call, but how do I go about using it?

>> why do you need to call lchown? it is almost a useless call. the owner
>> (or anyone with write permission) of the directory it is in can delete
>> it and recreate it. the ownership of a symlink never affects who can use
>> it so changing it means little.
> I am changing the uids and gids of all of my files on all of my
> systems.  This crosses about 15 different machines running solaris

All files? I hope you're not seriously considering doing this sort of
stuff in /usr and /etc and stuff, right? Did you mean all user-owned
files?

Quote:
> 2.x, freebsd, linux, and hp-ux.  I also am using clearcase so the
> targets may not actually be available outside of a clearcase view,
> and chown chokes on there being no target.  Since the current chown
> call dereferences a symlink and changes the target's uid/gid, this
> could be disastrous if the wrong uid is applied to a target file.  

Be careful. What happens if someone has a symlink to /etc/passwd and
/etc/shadow in their home directory? Or things like /etc/sudoers? or
even to init?

It would be much better to just skip symlinks alltogether, and limit
yourself to plain files and directories:

$ find /home/user -type f -o -type d | xargs chown user

This also gets around the problem of symlinks pointing to nothing.

Quote:
> Now while I can get around this, (and will), it begs the question
> since the source configuration checks if the lchown() call exists.
> :)

See my other post on this. I suspect that that was put in at some
point when there was discussion on making ;chown available from Perl,
and subsequently forgotten.

Quote:
> Oh, I just re-read your response.  you are correct about the
> symlink's permissions not affecting who can access files.  I expect
> to be getting a lot of queries about "why isn't this symlink owned
> by me".  Thus, I am really working to reduce the "pita" factor (pain
> in the a__).

The chown command on the various platforms can be made to work on
symlinks

$ CHOWN_OPTIONS="-some_platform_specific_option"
$ find /home/user -type l | xargs chown $CHOWN_OPTIONS

I think this could quite easily be done with a simple shell script,
unless there's more that you haven't told us yet.

Martien
--
                                |
Martien Verbruggen              | We are born {*filter*}, wet and hungry.
Trading Post Australia Pty Ltd  | Then things get worse.
                                |



Mon, 17 May 2004 22:47:24 GMT  
 chown, but no lchown
|>
|> why do you need to call lchown? it is almost a useless call. the owner
|> (or anyone with write permission) of the directory it is in can delete
|> it and recreate it. the ownership of a symlink never affects who can use
|> it so changing it means little.

   However, if you don't use lchown you have to check for yourself
whether what you are about to change is a symlink (which comes with the
usual race-condition associated with such things).  When you are running
an admin script you might well wish to chown the entries in "this"
directory but not what any symlinks point to.

   This is also why the chown command has a -h option.

--

This message *may* reflect my personal opinion.  It is *not* intended
to reflect those of my employer, or anyone else.



Mon, 17 May 2004 14:01:38 GMT  
 
 [ 9 post ] 

 Relevant Pages 

1. SunOS 5.x lchown

2. Anything lchown()-like in Perl?

3. Please help! (CHOWN / Nobody)

4. Chown'ing a symbolic link

5. chown question

6. Need help learning how to use chown correclty inside of a perl script

7. Chown and SymLinks

8. Bug in chown ?

9. doing chmod, chown & chgrp from perl

10. 0 21 * * 5 root /bin/chown 444 /usr/sbin/sendmail

11. How to chown and chmod

12. How to chown a symbolic link in Perl?

 

 
Powered by phpBB® Forum Software