zfs discuss - Aug 2009 - How to prevent /usr/bin/chmod from following symbolic links?

Hello!

How can I prevent /usr/bin/chmod from following symbolic links? I can''t
find any -P option in the documentation (and it doesn''t work either..).
Maybe find can be used in some way?

Background:
When I''m running chmod on my backup folder structure containing a copy
of a Linux root directory, I''m suddenly altering the permissions on
every single file on my OpenSolaris computer, something that eventually forces
me to hard reset it. If it wasn''t for single user mode and ZFS
shapshots, this would have been a really big problem... The reason seems to be
that the Linux file system contains a symbolic link to /.
-- 
This message posted from opensolaris.org

Kris Larsen wrote:
> 
> Hello!
> 
> How can I prevent /usr/bin/chmod from following symbolic links? I
can''t find any -P option in the documentation (and it doesn''t
work either..). Maybe find can be used in some way?
[snip]

Try:
1. Start ksh93
$ ksh93
2. Load "chmod" builtin command
$ builtin chmod
3. View help
$ chmod --man
or
$ chmod --help

Does that work for you ?

----

Bye,
Roland

-- 
  __ .  . __
 (o.\ \/ /.o) roland.mainz at nrubsig.org
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix
programmer
  /O /==\ O\  TEL +49 641 3992797
 (;O/ \/ \O;)

Thanks. It works for GNU-style chmod usage. But aren''t ACL''s
supported?
-- 
This message posted from opensolaris.org

On Aug 22, 2009, at 3:47 PM, Kris Larsen wrote:
> Thanks. It works for GNU-style chmod usage. But aren''t
ACL''s
> supported?
gnu chmod doesn''t do ACLs.

Back when I was managing lots of users and needed to do such things,
find scripts seemed to be much more useful and flexible. -R options can
make assumptions that I''d rather not make, especially when dealing with
special files. At one time, I even got fancy and had reports generated  
which
described what was found... you''d be amazed at how clever some
engineering students were ;-)
  -- richard

Kris Larsen wrote:
> 
> Thanks. It works for GNU-style chmod usage.
Erm... technically this isn''t GNU "chmod", it''s a
different "chmod"
implementation which includes GNU+BSD+MacOSX options...
> But aren''t ACL''s supported?
No, not yet... but it''s on my todo list (the tricky part is to find the
person who originally added ACL support to Solaris''s "chmod"
since I
have a couple of questions...) ... 

----

Bye,
Roland

-- 
  __ .  . __
 (o.\ \/ /.o) roland.mainz at nrubsig.org
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix
programmer
  /O /==\ O\  TEL +49 641 3992797
 (;O/ \/ \O;)

Ok.. A kind-of hybrid chmod then :)

Until you can figure out how to implement it, I probably have to do it this way.
Not too much extra work :)

find /backup/clients -type fd -exec /usr/bin/chmod -R
A=group:backup-owners:full_set:file_inherit/dir_inherit:allow {} \;
-- 
This message posted from opensolaris.org

>Hello!
>
>How can I prevent /usr/bin/chmod from following symbolic links? I
can''t find any
>-P option in the documentation (and it doesn''t work either..).
> Maybe find can be used in some way?

Not possible; in Solaris we don''t have a lchmod(2) system call which
makes
adding a chmod option (like chown) which don''t follow symbolic links. 
You
can clearly add it to OpenSolaris :-)

Casper

> >How can I prevent /usr/bin/chmod from following symbolic links? I
> can''t find any
> >-P option in the documentation (and it doesn''t work either..).
> > Maybe find can be used in some way?
> 
> 
> Not possible; in Solaris we don''t have a lchmod(2) system call
which
> makes
> adding a chmod option (like chown) which don''t follow symbolic
links.
> You
> can clearly add it to OpenSolaris :-)


It''s a strange question anyway - You want a single file to have
permissions
(suppose 755) in one directory, and some different permissions (suppost 700)
in some other directory?  Then some users could access the file if they use
path A, but would be denied access to the same file if they used path B?
That''s weird.

It makes no sense to attempt setting perms on a symlink.  The perms are
determined by the actual file.  The symlink is just another name for the
file itself.  If you want to change perms of the file, change the perms of
the file.

On Sun, 23 Aug 2009, Edward Ned Harvey wrote:
>
> It makes no sense to attempt setting perms on a symlink.  The perms are
> determined by the actual file.  The symlink is just another name for the
> file itself.  If you want to change perms of the file, change the perms of
> the file.
Actually it does make plenty of sense.  Not having control over this 
is a security problem.  It provides a way for someone to gain 
access/ownership to a file that they should not have access to or to 
screw up the system.  All one has to do is to create the requisite 
link in a place that you have access to, and then entice the victim to 
chmod the files for you.

Bob
--
Bob Friesenhahn
bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

>It''s a strange question anyway - You want a single file to have
permissions
>(suppose 755) in one directory, and some different permissions (suppost 700)
>in some other directory?  Then some users could access the file if they use
>path A, but would be denied access to the same file if they used path B?
>That''s weird.
>
>It makes no sense to attempt setting perms on a symlink.  The perms are
>determined by the actual file.  The symlink is just another name for the
>file itself.  If you want to change perms of the file, change the perms of
>the file.
I think the purpose, at least for Solaris, would be making sure that
chmod() doesn''t follow symlinks.  lchmod() used on a symbolic link
would
be a no-op.

Casper

> >It''s a strange question anyway - You want a single file to
have
> permissions
> >(suppose 755) in one directory, and some different permissions
> (suppost 700)
> >in some other directory?  Then some users could access the file if
> they use
> >path A, but would be denied access to the same file if they used path
> B?
> >That''s weird.
> >
> >It makes no sense to attempt setting perms on a symlink.  The perms
> are
> >determined by the actual file.  The symlink is just another name for
> the
> >file itself.  If you want to change perms of the file, change the
> perms of
> >the file.
> 
> I think the purpose, at least for Solaris, would be making sure that
> chmod() doesn''t follow symlinks.  lchmod() used on a symbolic link
> would
> be a no-op.

My point exactly.  I''m being bold or brazen or ignorant by saying: 
There is
no point to do a chmod and not follow symlink.  Chmod should always follow
symlinks.  That''s why it''s the default behavior, and
that''s why it''s rare,
strange, or impossible to override that behavior.

>My point exactly.  I''m being bold or brazen or ignorant by saying: 
There is
>no point to do a chmod and not follow symlink.  Chmod should always follow
>symlinks.  That''s why it''s the default behavior, and
that''s why it''s rare,
>strange, or impossible to override that behavior.

As long as you''re careful when you''re root.

Casper

On Mon, Aug 24, 2009 at 8:08 AM, Edward Ned Harvey<solaris at
nedharvey.com> wrote:
>> >It''s a strange question anyway - You want a single file to
have
>> permissions
>> >(suppose 755) in one directory, and some different permissions
>> (suppost 700)
>> >in some other directory? ?Then some users could access the file if
>> they use
>> >path A, but would be denied access to the same file if they used
path
>> B?
>> >That''s weird.
>> >
>> >It makes no sense to attempt setting perms on a symlink. ?The perms
>> are
>> >determined by the actual file. ?The symlink is just another name
for
>> the
>> >file itself. ?If you want to change perms of the file, change the
>> perms of
>> >the file.
>>
>> I think the purpose, at least for Solaris, would be making sure that
>> chmod() doesn''t follow symlinks. ?lchmod() used on a symbolic
link
>> would
>> be a no-op.
>
>
> My point exactly. ?I''m being bold or brazen or ignorant by saying:
?There is
> no point to do a chmod and not follow symlink. ?Chmod should always follow
> symlinks. ?That''s why it''s the default behavior, and
that''s why it''s rare,
> strange, or impossible to override that behavior.
No it shouldn''t.

Alice$ cd ~/proj1; ln -s /etc .,

Alice$ echo "Hi helpdesk, Bob is on vacation and he has a bunch of
files in my home directory for a project that we are working on
together.  Unfortunately, his umask was messed up and I can''t modify
the files in ~alice/proj1.  Can you do a ''chmod -fR a+rw
/home/alice/proj1'' for me?  Thanks!" | mailx -s "permissions
fix"

Helpdesk$ pfexec chmod -fR a+rw /home/alice/proj1

Alice$ rm /etc/shadow
Alice$ cp myshadow /etc
Alice$ su -
root#


-- 
Mike Gerdts
http://mgerdts.blogspot.com/

On Aug 24, 2009, at 8:32 AM, Mike Gerdts wrote:
> On Mon, Aug 24, 2009 at 8:08 AM, Edward Ned Harvey<solaris at
nedharvey.com
> > wrote:
>>>> It''s a strange question anyway - You want a single
file to have
>>> permissions
>>>> (suppose 755) in one directory, and some different permissions
>>> (suppost 700)
>>>> in some other directory?  Then some users could access the file
if
>>> they use
>>>> path A, but would be denied access to the same file if they
used
>>>> path
>>> B?
>>>> That''s weird.
>>>>
>>>> It makes no sense to attempt setting perms on a symlink.  The
perms
>>> are
>>>> determined by the actual file.  The symlink is just another
name
>>>> for
>>> the
>>>> file itself.  If you want to change perms of the file, change
the
>>> perms of
>>>> the file.
>>>
>>> I think the purpose, at least for Solaris, would be making sure
that
>>> chmod() doesn''t follow symlinks.  lchmod() used on a
symbolic link
>>> would
>>> be a no-op.
>>
>>
>> My point exactly.  I''m being bold or brazen or ignorant by
saying:
>> There is
>> no point to do a chmod and not follow symlink.  Chmod should always  
>> follow
>> symlinks.  That''s why it''s the default behavior, and
that''s why
>> it''s rare,
>> strange, or impossible to override that behavior.
>
> No it shouldn''t.
>
> Alice$ cd ~/proj1; ln -s /etc .,
>
> Alice$ echo "Hi helpdesk, Bob is on vacation and he has a bunch of
> files in my home directory for a project that we are working on
> together.  Unfortunately, his umask was messed up and I can''t
modify
> the files in ~alice/proj1.  Can you do a ''chmod -fR a+rw
> /home/alice/proj1'' for me?  Thanks!" | mailx -s
"permissions fix"
Yeah, but that is just a social engineering attack.
If you change chmod, you can just change the suggested
command, and achieve similar results. cp and rm are favorite
targets, too.  IMHO, the real problem here is that there is a
multitude of cp, rm, chmod, ls, and other commands or shell
builtins -- most folks won''t know which one they are currently using
:-(
  -- richard
>
> Helpdesk$ pfexec chmod -fR a+rw /home/alice/proj1
>
> Alice$ rm /etc/shadow
> Alice$ cp myshadow /etc
> Alice$ su -
> root#
>
>
> -- 
> Mike Gerdts
> http://mgerdts.blogspot.com/
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

On Mon, Aug 24, 2009 at 12:55, Richard Elling<richard.elling at gmail.com>
wrote:
>> Alice$ cd ~/proj1; ln -s /etc .,
>>
>> Alice$ echo "Hi helpdesk, Bob is on vacation and he has a bunch of
>> files in my home directory for a project that we are working on
>> together. ?Unfortunately, his umask was messed up and I can''t
modify
>> the files in ~alice/proj1. ?Can you do a ''chmod -fR a+rw
>> /home/alice/proj1'' for me? ?Thanks!" | mailx -s
"permissions fix"
>
> Yeah, but that is just a social engineering attack.
> If you change chmod, you can just change the suggested
> command, and achieve similar results.
That''s not the point.  There is indeed some social engineering at work
here, getting the admin to run chmod, but the point is the directory
/home/alice/proj1 looks innocent until one examines the contents.  So
unless the helpdesk notices the symlink to /etc/shadow somewhere in
that directory tree, the request contains no hint of malicious intent.
>> Helpdesk$ pfexec chmod -fR a+rw /home/alice/proj1
>>
>> Alice$ rm /etc/shadow
>> Alice$ cp myshadow /etc
>> Alice$ su -
>> root#
One could achieve the same result with a request to chmod a+rw
/etc/shadow, but this would be more noticeable.

One of my friends ran into this problem while trying to set an ACL on
his data files: chmod followed symlinks that he had created to his
home directory and config files in /etc, and broke his whole install.
I agree chmod should not follow symlinks.

Will

On Aug 24, 2009, at 10:22 AM, Will Murnane wrote:
> On Mon, Aug 24, 2009 at 12:55, Richard  
> Elling<richard.elling at gmail.com> wrote:
>>> Alice$ cd ~/proj1; ln -s /etc .,
>>>
>>> Alice$ echo "Hi helpdesk, Bob is on vacation and he has a
bunch of
>>> files in my home directory for a project that we are working on
>>> together.  Unfortunately, his umask was messed up and I
can''t modify
>>> the files in ~alice/proj1.  Can you do a ''chmod -fR a+rw
>>> /home/alice/proj1'' for me?  Thanks!" | mailx -s
"permissions fix"
>>
>> Yeah, but that is just a social engineering attack.
>> If you change chmod, you can just change the suggested
>> command, and achieve similar results.
> That''s not the point.  There is indeed some social engineering at
work
> here, getting the admin to run chmod, but the point is the directory
> /home/alice/proj1 looks innocent until one examines the contents.  So
> unless the helpdesk notices the symlink to /etc/shadow somewhere in
> that directory tree, the request contains no hint of malicious intent.
>
>>> Helpdesk$ pfexec chmod -fR a+rw /home/alice/proj1
>>>
>>> Alice$ rm /etc/shadow
>>> Alice$ cp myshadow /etc
>>> Alice$ su -
>>> root#
> One could achieve the same result with a request to chmod a+rw
> /etc/shadow, but this would be more noticeable.
>
> One of my friends ran into this problem while trying to set an ACL on
> his data files: chmod followed symlinks that he had created to his
> home directory and config files in /etc, and broke his whole install.
A normal user cannot chmod in /etc. So he was really running as
root, no? As root or a sufficiently privileged user, there are many
things that you need to be aware of. Again, I use find to do the
right thing and keep a record of the activity -- see the -mount, -user,
and -type options.
> I agree chmod should not follow symlinks.
I''m leaning this way, too. But it is not clear to me what will break
in the other direction. I know many people and ISVs who setup
symlinked directory structures as a standard practice.
  -- richard

Will Murnane <will.murnane at gmail.com> wrote:
> >> Helpdesk$ pfexec chmod -fR a+rw /home/alice/proj1
> >>
> >> Alice$ rm /etc/shadow
> >> Alice$ cp myshadow /etc
> >> Alice$ su -
> >> root#
> One could achieve the same result with a request to chmod a+rw
> /etc/shadow, but this would be more noticeable.
>
> One of my friends ran into this problem while trying to set an ACL on
> his data files: chmod followed symlinks that he had created to his
> home directory and config files in /etc, and broke his whole install.
> I agree chmod should not follow symlinks.
I am not sure whether Sun people will understand that many of the usual 
attacks may be prevented with proper checks in the userland programs.

Sun tar still allows you to use hand crafted archives that force Sun tar
(or any other dumb tar implementation) to remove arbitrary files in case that
the archive is unpacked. Given the fact that this may be hidden inside a large
archive, it may stay undiscovered for a long time.

Star prevents this from happening......

lchmod() is a simple way to prevent frequent problems.

J?rg

-- 
 EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin
       js at cs.tu-berlin.de                (uni)  
       joerg.schilling at fokus.fraunhofer.de (work) Blog:
http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily

Richard Elling <richard.elling at gmail.com> wrote:
> >>> Helpdesk$ pfexec chmod -fR a+rw /home/alice/proj1
> >>>
> >>> Alice$ rm /etc/shadow
> >>> Alice$ cp myshadow /etc
> >>> Alice$ su -
> >>> root#
> > One could achieve the same result with a request to chmod a+rw
> > /etc/shadow, but this would be more noticeable.
> >
> > One of my friends ran into this problem while trying to set an ACL on
> > his data files: chmod followed symlinks that he had created to his
> > home directory and config files in /etc, and broke his whole install.
>
> A normal user cannot chmod in /etc. So he was really running as
> root, no? As root or a sufficiently privileged user, there are many
> things that you need to be aware of. Again, I use find to do the
> right thing and keep a record of the activity -- see the -mount, -user,
> and -type options.
Do you believe that root should not get help that allows to easily 
prevent problems from hitting symlinks?


J?rg

-- 
 EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin
       js at cs.tu-berlin.de                (uni)  
       joerg.schilling at fokus.fraunhofer.de (work) Blog:
http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily

On Mon, Aug 24, 2009 at 5:55 PM, Richard Elling<richard.elling at
gmail.com> wrote:
>
...
>> No it shouldn''t.
>>
>> Alice$ cd ~/proj1; ln -s /etc .,
>>
>> Alice$ echo "Hi helpdesk, Bob is on vacation and he has a bunch of
>> files in my home directory for a project that we are working on
>> together. ?Unfortunately, his umask was messed up and I can''t
modify
>> the files in ~alice/proj1. ?Can you do a ''chmod -fR a+rw
>> /home/alice/proj1'' for me? ?Thanks!" | mailx -s
"permissions fix"
>
> Yeah, but that is just a social engineering attack.
> If you change chmod, you can just change the suggested
> command, and achieve similar results. cp and rm are favorite
> targets, too. ?IMHO, the real problem here is that there is a
> multitude of cp, rm, chmod, ls, and other commands or shell
> builtins -- most folks won''t know which one they are currently
using :-(
It''s not *just* a social engineering attack. It''s relying on
the fact that
(unlike chown -h) the chmod command follows symlinks and there''s
no way to disable that behaviour.

-- 
-Peter Tribble
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/

Remove the -R after chmod when running this command! Adding -R here is of course
just as dangerous as running it without find. Lesson learned:
Cut''n''paste is dangerous..
-- 
This message posted from opensolaris.org