[Chicago-talk] chown inside a script
me at heyjay.com
Thu Dec 6 11:39:51 PST 2007
I figured if I showed my hand, everyone would call me a crazy person
with an insecure system (which I'm not denying).
Here's the deal:
I run a MS application to which the files are stored on my samba
server. Currently, when a user creates a file, that user/owner is the
only user with read (and write) access to said file. BUT, when the
file is "closed", I (me), the manager, use the application to move the
file from one "folder" to a different "folder". Behind the scenes the
app, copies the file from one directory to another, and deletes the
As a result, I (jstrauss), become the owner of the file, and the
person who created it, no longer has access. I want to retain the
original ownership, so that the creator can still look at the file
(but no one else can).
So I wrote a cgi to change ownership, rather than sshing to the box,
cd'ing to the directory, looking up the filename in the application,
and then chown'ing filname*, everytime someone wants to see a "closed"
If there are better, easier, more secure ways to do this I'd welcome
suggestions. Please NOTE, the webserver is an internal webserver
(behind my firewall), and my company includes me and 3 employees
(really only 2.5 if you measured productivity :).
On Dec 6, 2007 9:59 AM, Ted Zlatanov <tzz at lifelogs.com> wrote:
> On Wed, 05 Dec 2007 22:38:10 -0600 Jonathan Rockway <jon at jrock.us> wrote:
> JR> On Wed, 2007-12-05 at 22:28 -0600, Jay Strauss wrote:
> >> Thanks.
> >> But I don't think that will work in my case, because I'm doing it from
> >> a web page, I had to create an suid link to chown, to call from my
> >> cgi.
> >> Unless there is some way to do it from inside perl, but still change
> >> ownership of file not owned by the webserver.
> JR> This is a massive security nightmare. Consider the case where someone
> JR> symlinks /path/that/matches/your.glob to /etc/shadow. You've just
> JR> rendered the system unusable.
> JR> Also, keep in mind that you can't create a "setuid link". chmod follows
> JR> symlinks and updates the original file.
> I think chroot to a known good path that contains only data files (plus
> a minimal chown setup) would work. Symlinks to the outside won't
> resolve inside such an environment. Hard links will, if the filesystem
> was shared, so don't put the data files on the /etc filesystem. The
> worst an attacker could do is corrupt the data inside the chroot
> environment. It's a pain to set it all up, though.
> Chicago-talk mailing list
> Chicago-talk at pm.org
More information about the Chicago-talk