f



File/directory access

Hello all,

   I'm running perforce on an NetBSD system, and I was wondering about a
few things..

   I have created a 'p4admin' group, and a 'perforce' user. The
directory where perforce's files reside belongs to group 'p4admin' and
has the owner 'perforce'. The owner has full rwx right, but the group
only has r-- rights.

   This will allow me to add my user to the 'p4admin' group, and use it
to backup the perforce files. This works great apart from one little
detail..

   The perforce daemon files are located in:
/var/perforce/serverroot (I understand this may be unconventional, but
ignore that for a while).

   I can backup all the files there with my user. The problem is related
to the fact that each "depot" I create is contained within a
subdirectory under the serverroot. i.e.:

/var/perforce/serverroot/depot
/var/perforce/serverroot/depot/project1
/var/perforce/serverroot/depot/project1/src
....
etc

From now on, I'm talking about group permissions (p4admin).

   In my backup script, I need to backup all the files in serverroot/
(works), and everything under depot/ - which fails because the group's
permission does not include 'x'.

   Now, I could simply run "chmod -R 750 depot/", but that would make
all the files executable as well, which I don't want. And even if it
didn't, the next directory I create would (again) not have the 'x'
attribute. I could change the umask for the daemon, but that would make
all files executable (right?).

   So, what I would want to do is to make any new *directory* have 'x'
set, while files don't.

It is solveable?
0
Jan
7/23/2005 9:07:31 PM
comp.unix.misc 550 articles. 0 followers. underh20.scubadiving (150) is leader. Post Follow

2 Replies
257 Views

Similar Articles

[PageSpeed] 12

Jan Danielsson <jan.danielsson@gmail.com> writes:

>    Now, I could simply run "chmod -R 750 depot/", but that would make
> all the files executable as well, which I don't want. And even if it
> didn't, the next directory I create would (again) not have the 'x'
> attribute. I could change the umask for the daemon, but that would make
> all files executable (right?).
> 
>    So, what I would want to do is to make any new *directory* have 'x'
> set, while files don't.

I would do an   find -type d | xargs chmod g+x   and set the umask to
027, if you want deny all access of "other".  That makes all existing
and newly created directories searchable for user and group.  Newly
created files only have the executable bit set, if they are created
that way e.g. with creat("filename", 0777) which is done by the linker
for example or when copying an executable file.  Why don't you want
executable file to be executable for the group?  If group members can
read the file you don't loose any security by also letting them
execute the file, unless it is also setuid or setgid.

urs
0
Urs
7/24/2005 1:05:41 AM
Urs Thuermann wrote:
[---]
>>   So, what I would want to do is to make any new *directory* have 'x'
>>set, while files don't.
> 
> I would do an   find -type d | xargs chmod g+x   and set the umask to
> 027, if you want deny all access of "other".  That makes all existing
> and newly created directories searchable for user and group.  Newly
> created files only have the executable bit set, if they are created
> that way e.g. with creat("filename", 0777) which is done by the linker
> for example or when copying an executable file.

   Thanks; that's exactly the information I was looking for. I changed
the daemons startup script to use umask 027, and it did exactly what I
wanted.

>Why don't you want
> executable file to be executable for the group? 

   It's just a directory which contains meta data -- nothing is supposed
to be executable there. When users connect to the server and request the
latest revisions of the files, they will be given the real files with
the proper permissions (not necessarily the same as in the serverroot
directory).

Now I got it all working as I want it to. Many thanks, again.
0
Jan
7/24/2005 3:17:30 PM
Reply: