savely change permission and group on files

[Lars Madsen]

Hi,

I have a small problem here. We have a special directory on our file
system (Linux) where a lot of people are writing to (mostly HTML pages,
no we do not have a CMS, this low tech is fine for now).

Now we also have some secretaries who can help edit these files. The
problems is of course permissions, secretary B need to be able to edit
the files owned by user A.

Solution: Put the necessary people in a special group and make sure that
the files are writable for that group. That's fine, but people tend to
forget setting permissions or changing groups, so I'd like to have a
cron job that goes through all files in a specific directory and set the
group and permissions on all files in this directory-tree.

That's easy to do, well sort of. The problem is of course that this cron
job has to run as root (or similar) and then we are vulnerable to user
input, as in file names such as 'file.html;rm -rf /'

So my question is this: how can one safely change the group and group
permissions in such a case as this. Or more generally how can one run
system commands safely on potentially dangerous data?

/daleif

 

[Anno Siegel]

Hi,

I have a small problem here. We have a special directory on our file
system (Linux) where a lot of people are writing to (mostly HTML pages,
no we do not have a CMS, this low tech is fine for now).

Now we also have some secretaries who can help edit these files. The
problems is of course permissions, secretary B need to be able to edit
the files owned by user A.

Solution: Put the necessary people in a special group and make sure that
the files are writable for that group. That's fine, but people tend to
forget setting permissions or changing groups, so I'd like to have a
cron job that goes through all files in a specific directory and set the
group and permissions on all files in this directory-tree.

That's easy to do, well sort of. The problem is of course that this cron
job has to run as root (or similar) and then we are vulnerable to user
input, as in file names such as 'file.html;rm -rf /'

So my question is this: how can one safely change the group and group
permissions in such a case as this. Or more generally how can one run
system commands safely on potentially dangerous data?

Firstly, a file name like that is only dangerous if you let a shell
interpret it. "chmod" by itself will fail, or change the permissions
if you managed to create a file of that name. So use the list form
of system(), which doesn't employ a shell. perldoc -f system.

Secondly, you don't need an external command at all to change the
file group. perldoc -f chown.

Thirdly, though this has nothing to do with Perl, you can set the group
of the enclosing directory to the common one and set its sgid bit. Under
Linux (and other BSD-derived systems) files and directories created in
that directory will be in the same group per default. man chmod.

Anno

 

[Aaron Baugher]

Solution: Put the necessary people in a special group and make sure
that the files are writable for that group. That's fine, but people
tend to forget setting permissions or changing groups, so I'd like
to have a cron job that goes through all files in a specific
directory and set the group and permissions on all files in this
directory-tree.

Not really a perl problem:

#!/bin/sh
if cd /wherever; then
chgrp -R ourgroup .
chmod -R g+rw .
fi

 

[Lars Madsen]

Firstly, a file name like that is only dangerous if you let a shell
interpret it. "chmod" by itself will fail, or change the permissions
if you managed to create a file of that name. So use the list form
of system(), which doesn't employ a shell. perldoc -f system.

ok

Secondly, you don't need an external command at all to change the
file group. perldoc -f chown.

I know

Thirdly, though this has nothing to do with Perl, you can set the group
of the enclosing directory to the common one and set its sgid bit. Under
Linux (and other BSD-derived systems) files and directories created in
that directory will be in the same group per default. man chmod.

hmm, never even thought of that

thanks

/daleif

 

[Jürgen Exner]

Lars Madsen wrote:
[...]

Now we also have some secretaries who can help edit these files. The
problems is of course permissions, secretary B need to be able to edit
the files owned by user A.

Solution: Put the necessary people in a special group and make sure
that the files are writable for that group. That's fine, but people
tend to forget setting permissions or changing groups,

Why not set the SetGUID bit on the directory?

so I'd like to
have a cron job that goes through all files in a specific directory
and set the group and permissions on all files in this directory-tree.

[complicated proposal snipped]

jue

 

[Lars Madsen]

Not really a perl problem:

#!/bin/sh
if cd /wherever; then
chgrp -R ourgroup .
chmod -R g+rw .
fi

yes that's true, but real life is of cource not as simple as the case I
described.

One problem with this is that it allows users to create directories in
/whatever (creating them in subdirectories are fine) which we don't want.

I'll find some compromise

/daleif

 

[Aaron Baugher]

yes that's true, but real life is of cource not as simple as the
case I described.

One problem with this is that it allows users to create directories
in /whatever (creating them in subdirectories are fine) which we
don't want.

So add the line 'chmod g-w .' right before the 'fi' line to remove
group write permissions from the top directory.

 

[Lars Madsen]

Huh? I don't get it. Why would you be vulnerable if you're doing something
simple as changing the permissions of files?

if one (by mistake) runs sys commands on unchecked data

as in doing a naive delete of a file named '-rf /'


/daleif

 

[Michael Greb]

Lars Madsen ([email protected]) wrote on MMMMDLIX September MCMXCIII in
<URL:??
?? > Huh? I don't get it. Why would you be vulnerable if you're doing
something
?? > simple as changing the permissions of files?
?? >
??
?? if one (by mistake) runs sys commands on unchecked data

If you are afraid you make mistakes like that, you shouldn't program
at all. There's no defence.

?? as in doing a naive delete of a file named '-rf /'


Huh? A native delete of a file in Perl is quite safe, and spelled 'unlink'.

'native' ne 'naive'

 

[Juha Laiho]

I have a small problem here. We have a special directory on our file
system (Linux) where a lot of people are writing to (mostly HTML pages,
no we do not have a CMS, this low tech is fine for now).

Now we also have some secretaries who can help edit these files. The
problems is of course permissions, secretary B need to be able to edit
the files owned by user A.

The 'chmod g+s' solution is pretty much correct. The only potential problem
is someone who sets their umask (file creation mask) to a too strict
value (f.ex. 066, to prohibit all acess to created files from everyone
but the creator).

Depending on your Linux distribution, it may support a more sophisticated
way to control file access, called ACLs (access control lists). These
can be defined to be inherited by newly created objects, and can be set
to provide required level of access - and this solution should be
resistent to the umask "problem" described above.

This message is crossposted in comp.os.linux.misc, and followups are
directed to the same; if you need further help with the ACLs (they
can be a pain..), please continue in that group.