Allow creation of files, prevent creation of sub-directories
in [Shell]
|
Prev: two sed commands , want to reduce to one sed command
Next: Free Online Subversion Training - All About Subversion Hook Scripts
From: Scott Bass on 12 May 2010 00:45 Hi, Is there a security setting in Unix that allows the creation of files within a set of sub-directories, but prevents the creation of additional sub-directories? Thanks, Scott
From: Scott Bass on 13 May 2010 01:21 On May 12, 3:06 pm, Michael Vilain <vil...(a)NOspamcop.net> wrote: > In article > <da961272-1d80-4673-a66f-7ddeb095e...(a)a34g2000yqn.googlegroups.com>, > Scott Bass <sas_l_...(a)yahoo.com.au> wrote: > > > Hi, > > > Is there a security setting in Unix that allows the creation of files > > within a set of sub-directories, but prevents the creation of > > additional sub-directories? > > > Thanks, > > Scott > > Once you have write access to the directory, you can create files in > that directory, including directories inside the directory. > > What problem are you trying to solve here? > > -- > DeeDee, don't press that button! DeeDee! NO! Dee... > [I filter all Goggle Groups posts, so any reply may be automatically ignored] (I only have access to Usenet via Google Groups from work :-( Hope you get this reply...) Hi Michael, Thanks for the reply. We have a standard set of directories set up for each project, which are setup by the system administrator. The programmers then put their code in the appropriate directories. Some of our scripts are reliant on this pre-configured directory structure. Creating additional sub-directories causes problems. I was hoping there was some setting (sticky bit, trickery with group membership, ???) that would allow the programmers to have full control (create/modify/delete) of regular files in the pre-configured sub- directories, but prevent them from creating additional sub- directories. We could just tell them "don't do that", but that never works... Thanks, Scott
From: Scott Bass on 13 May 2010 02:29 On May 13, 3:36 pm, Michael Vilain <vil...(a)NOspamcop.net> wrote: > In article > <834dd589-b13f-41fd-bf2a-888aef452...(a)k29g2000yqh.googlegroups.com>, > Scott Bass <sas_l_...(a)yahoo.com.au> wrote: > > > > > On May 12, 3:06 pm, Michael Vilain <vil...(a)NOspamcop.net> wrote: > > > In article > > > <da961272-1d80-4673-a66f-7ddeb095e...(a)a34g2000yqn.googlegroups.com>, > > > Scott Bass <sas_l_...(a)yahoo.com.au> wrote: > > > > > Hi, > > > > > Is there a security setting in Unix that allows the creation of files > > > > within a set of sub-directories, but prevents the creation of > > > > additional sub-directories? > > > > > Thanks, > > > > Scott > > > > Once you have write access to the directory, you can create files in > > > that directory, including directories inside the directory. > > > > What problem are you trying to solve here? > > > > -- > > > DeeDee, don't press that button! DeeDee! NO! Dee... > > > [I filter all Goggle Groups posts, so any reply may be automatically > > > ignored] > > > (I only have access to Usenet via Google Groups from work :-( Hope > > you get this reply...) > > > Hi Michael, > > > Thanks for the reply. > > > We have a standard set of directories set up for each project, which > > are setup by the system administrator. The programmers then put their > > code in the appropriate directories. > > > Some of our scripts are reliant on this pre-configured directory > > structure. Creating additional sub-directories causes problems. > > > I was hoping there was some setting (sticky bit, trickery with group > > membership, ???) that would allow the programmers to have full control > > (create/modify/delete) of regular files in the pre-configured sub- > > directories, but prevent them from creating additional sub- > > directories. > > > We could just tell them "don't do that", but that never works... > > > Thanks, > > Scott > > 'Fraid UNIX doesn't work that way. Your only way to fix this is with > the 2x4 with the rusty nail in it. Depending on the OS, the best you > can do is set the sticky bit to allow anyone to create files (and > directories) in a directory. But they'll be owned by the developer that > created them. If this is a development environment, that shouldn't be a > problem. If this is production, you have a _BIG_ problem. Developers > shouldn't be on a production systems because they'll screw it up. > > Seriously. There's nothing that will restrict a process from creating > files in a directory if they have write access to that directory in > UNIX. Even ACLs won't stop that. Use the 2x4. That works. Along with > HR escorting them out the door. > > If you can't get that through management's head, then you have bigger > problems. Just set stuff to all access and let them f* it up as you > turn in your resignation. Someone else will clean up the mess. > > -- > DeeDee, don't press that button! DeeDee! NO! Dee... > [I filter all Goggle Groups posts, so any reply may be automatically ignored] Hi Michael, love the reply :-) Thanks for the mini-education into Unix file security. At least knowing "it doesn't work that way" is useful information.
From: Jon LaBadie on 13 May 2010 09:24 Scott Bass wrote: > On May 12, 3:06 pm, Michael Vilain <vil...(a)NOspamcop.net> wrote: >> In article >> <da961272-1d80-4673-a66f-7ddeb095e...(a)a34g2000yqn.googlegroups.com>, >> Scott Bass <sas_l_...(a)yahoo.com.au> wrote: >> >>> Hi, >>> Is there a security setting in Unix that allows the creation of files >>> within a set of sub-directories, but prevents the creation of >>> additional sub-directories? >>> Thanks, >>> Scott >> Once you have write access to the directory, you can create files in >> that directory, including directories inside the directory. >> >> What problem are you trying to solve here? >> >> -- >> DeeDee, don't press that button! DeeDee! NO! Dee... >> [I filter all Goggle Groups posts, so any reply may be automatically ignored] > > (I only have access to Usenet via Google Groups from work :-( Hope > you get this reply...) > > Hi Michael, > > Thanks for the reply. > > We have a standard set of directories set up for each project, which > are setup by the system administrator. The programmers then put their > code in the appropriate directories. > > Some of our scripts are reliant on this pre-configured directory > structure. Creating additional sub-directories causes problems. > If it is only a problem when the scripts run, I'm thinking things like build an application scripts, then perhaps you can write an additional script that checks and confirms the desired structure is intact and not extended. I can think of two actions the script could take, though there certainly could be others - just report via exit status, messages, logs, email, etc. or it could be draconian and remove the offending directories and/or add the missing ones. Such a script could be called early in each script that depends on the directory structure. Certainly notify the developers you are doing this, and if complaints get too loud, perhaps set up a jail directory for each developer or tree where offending directories could be moved rather than removed. > I was hoping there was some setting (sticky bit, trickery with group > membership, ???) that would allow the programmers to have full control > (create/modify/delete) of regular files in the pre-configured sub- > directories, but prevent them from creating additional sub- > directories. > > We could just tell them "don't do that", but that never works... > > Thanks, > Scott
From: Mick on 13 May 2010 09:34
On 05/13/2010 01:36 AM, Michael Vilain wrote: > In article > <834dd589-b13f-41fd-bf2a-888aef4529b9(a)k29g2000yqh.googlegroups.com>, > Scott Bass<sas_l_739(a)yahoo.com.au> wrote: > >> On May 12, 3:06 pm, Michael Vilain<vil...(a)NOspamcop.net> wrote: >>> In article >>> <da961272-1d80-4673-a66f-7ddeb095e...(a)a34g2000yqn.googlegroups.com>, >>> Scott Bass<sas_l_...(a)yahoo.com.au> wrote: >>> >>>> Hi, >>> >>>> Is there a security setting in Unix that allows the creation of files >>>> within a set of sub-directories, but prevents the creation of >>>> additional sub-directories? >>> >>>> Thanks, >>>> Scott >>> >>> Once you have write access to the directory, you can create files in >>> that directory, including directories inside the directory. >>> >>> What problem are you trying to solve here? >>> >>> -- >>> DeeDee, don't press that button! DeeDee! NO! Dee... >>> [I filter all Goggle Groups posts, so any reply may be automatically >>> ignored] >> >> (I only have access to Usenet via Google Groups from work :-( Hope >> you get this reply...) >> >> Hi Michael, >> >> Thanks for the reply. >> >> We have a standard set of directories set up for each project, which >> are setup by the system administrator. The programmers then put their >> code in the appropriate directories. >> >> Some of our scripts are reliant on this pre-configured directory >> structure. Creating additional sub-directories causes problems. >> >> I was hoping there was some setting (sticky bit, trickery with group >> membership, ???) that would allow the programmers to have full control >> (create/modify/delete) of regular files in the pre-configured sub- >> directories, but prevent them from creating additional sub- >> directories. >> >> We could just tell them "don't do that", but that never works... >> >> Thanks, >> Scott > > 'Fraid UNIX doesn't work that way. Your only way to fix this is with > the 2x4 with the rusty nail in it. Depending on the OS, the best you > can do is set the sticky bit to allow anyone to create files (and > directories) in a directory. But they'll be owned by the developer that > created them. If this is a development environment, that shouldn't be a > problem. If this is production, you have a _BIG_ problem. Developers > shouldn't be on a production systems because they'll screw it up. > > Seriously. There's nothing that will restrict a process from creating > files in a directory if they have write access to that directory in > UNIX. Even ACLs won't stop that. Use the 2x4. That works. Along with > HR escorting them out the door. > > If you can't get that through management's head, then you have bigger > problems. Just set stuff to all access and let them f* it up as you > turn in your resignation. Someone else will clean up the mess. > Use a project management tool let that tool have access and control what its users can and can not do. |