Did you trie to use the share parameters
force group = ...
create mask = ...
directory mask = ...
In our installation they work pretty well.
Jann
---
Jann Wegner
Institut fuer Demoskopie Allensbach, EDV
fon +49 7533 805148
On Wed, Feb 18, 2004 at 02:15:36AM +0100, Javier Fern?ndez-Sanguino Pe?a wrote:
> On Tue, Feb 17, 2004 at 03:12:44PM -0600, Hhayes wrote:
> > I have a Debian box running as a file server on a network with 50 users. So
> (...)
> > saved the file, resulting in a file that no other users can write to.
On Wed, Feb 18, 2004 at 02:15:36AM +0100, Javier Fern?ndez-Sanguino Pe?a wrote:
> On Tue, Feb 17, 2004 at 03:12:44PM -0600, Hhayes wrote:
> > I have a Debian box running as a file server on a network with 50 users. So
> (...)
> > saved the file, resulting in a file that no other users can write to.
On Thu, 19 Feb 2004 09:12, Michael Stone <[EMAIL PROTECTED]> wrote:
> On Wed, Feb 18, 2004 at 11:50:27PM +1100, Russell Coker wrote:
> >The other way of doing it properly is to write a program that open's each
> >file, calls fstat() to check the UID/GID, then uses fchown() or fchmod().
> >
> >It wo
On Thu, 19 Feb 2004 09:12, Michael Stone <[EMAIL PROTECTED]> wrote:
> On Wed, Feb 18, 2004 at 11:50:27PM +1100, Russell Coker wrote:
> >The other way of doing it properly is to write a program that open's each
> >file, calls fstat() to check the UID/GID, then uses fchown() or fchmod().
> >
> >It wo
Le 12466ième jour après Epoch,
Michael Stone écrivait:
> On Wed, Feb 18, 2004 at 11:50:27PM +1100, Russell Coker wrote:
>> The other way of doing it properly is to write a program that open's
>> each file, calls fstat() to check the UID/GID, then uses fchown() or
>> fchmod().
>>
>> It would be nic
Le 12466ième jour après Epoch,
Michael Stone écrivait:
> On Wed, Feb 18, 2004 at 11:50:27PM +1100, Russell Coker wrote:
>> The other way of doing it properly is to write a program that open's
>> each file, calls fstat() to check the UID/GID, then uses fchown() or
>> fchmod().
>>
>> It would be nic
Well done Stefano!
Hhayes, have a look at your mask setting near the top of
/etc/samba/samba.conf. You should be able to make samba behave the way
you want, even with Excel files, now you know that Excel is deleting
then rewriting the files.
Another way to prove files were being deleted and
A user can override the system default by putting their own umask
command in $HOME/.bashrc after the line that reads the system default.
On 02/19/04 04:11, Hhayes wrote:
Changing the umask to 007 didn't have any effect on the problem. So far
I've tried 000 and 007.
Well done Stefano!
Hhayes, have a look at your mask setting near the top of
/etc/samba/samba.conf. You should be able to make samba behave the way
you want, even with Excel files, now you know that Excel is deleting
then rewriting the files.
Another way to prove files were being deleted and
A user can override the system default by putting their own umask
command in $HOME/.bashrc after the line that reads the system default.
On 02/19/04 04:11, Hhayes wrote:
Changing the umask to 007 didn't have any effect on the problem. So far
I've tried 000 and 007.
--
To UNSUBSCRIBE, email
On 02/18/04 17:24, David Ehle wrote:
2) Referring back to your original post, the only user who can change
the owner of a file is the owner of that file, with the chown command.
Even this is a little complex as a normal user can NOT give away ownership
of their files. I guess people we
On Wed, Feb 18, 2004 at 01:59:37PM +0100, Javier Fernández-Sanguino Peña wrote:
That is, of course, if the partitions in the system have not been setup
properly.
What "properly"? Use a symlink instead of a hard link, you get the same
result but with a different race. Or use the old "make a dee
On Wed, Feb 18, 2004 at 11:50:27PM +1100, Russell Coker wrote:
The other way of doing it properly is to write a program that open's each
file, calls fstat() to check the UID/GID, then uses fchown() or fchmod().
It would be nice if someone was to patch the -R option of chown/chgrp/chmod in
core
On 02/18/04 17:24, David Ehle wrote:
2) Referring back to your original post, the only user who can change
the owner of a file is the owner of that file, with the chown command.
Even this is a little complex as a normal user can NOT give away ownership
of their files. I guess people were u
On Wed, Feb 18, 2004 at 02:23:30PM +0100, Javier Fernández-Sanguino Peña wrote:
Hmmm.. I did say there was plenty of room for improvement, after all,
obviously shell scripting is more prone to failure than a proper program
in C but let's give it a shot:
You're barking up the wrong tree. You ca
On Wed, Feb 18, 2004 at 01:59:37PM +0100, Javier Fernández-Sanguino Peña wrote:
That is, of course, if the partitions in the system have not been setup
properly.
What "properly"? Use a symlink instead of a hard link, you get the same
result but with a different race. Or use the old "make a deep d
On Wed, Feb 18, 2004 at 11:50:27PM +1100, Russell Coker wrote:
The other way of doing it properly is to write a program that open's each
file, calls fstat() to check the UID/GID, then uses fchown() or fchmod().
It would be nice if someone was to patch the -R option of chown/chgrp/chmod in
coreut
On Wed, Feb 18, 2004 at 02:23:30PM +0100, Javier Fernández-Sanguino Peña wrote:
Hmmm.. I did say there was plenty of room for improvement, after all,
obviously shell scripting is more prone to failure than a proper program
in C but let's give it a shot:
You're barking up the wrong tree. You can't
I didn't realize that Excel did that, but you are right. I just noticed
that it is only effecting Excel files. It just so happend that the
directories that I was looking at contained only Excel files, but after
checking, all other file types seem to be working fine.
Thanks.
"Stefano Salvi" <[EM
I didn't realize that Excel did that, but you are right. I just noticed
that it is only effecting Excel files. It just so happend that the
directories that I was looking at contained only Excel files, but after
checking, all other file types seem to be working fine.
Thanks.
"Stefano Salvi" <[EM
At 09.11 18/02/2004 -0600, Hhayes wrote:
After saving the file, if I run a ls -l on
the directory the file permissions on the file I opened are set to "hhayes"
as the owner with rw permission, and the group is set to "users" with only r
permission. I am not deleting the file and recreating it, o
Wow, this is so completely OT I like it...
On Wednesday, 2004-02-18 at 13:58:59 +0100, Ivan Brezina wrote:
> hmm, xargs does not use quotes when executing commands. This causes
> problems with dirs with spaces in name.
> If user has directory named "dummy root", he can easily get accsess to
> /
On Wed, Feb 18, 2004 at 01:58:59PM +0100, Ivan Brezina wrote:
> [...]
>
> hmm, xargs does not use quotes when executing commands. This causes
> problems with dirs with spaces in name.
> If user has directory named "dummy root", he can easily get accsess to
> /root directory.
Use "find -print0" a
Changing the umask to 007 didn't have any effect on the problem. So far
I've tried 000 and 007.
You said:
> 2) Referring back to your original post, the only user who can change
> the owner of a file is the owner of that file, with the chown command.
> For someone else to apparently change the ow
At 09.11 18/02/2004 -0600, Hhayes wrote:
After saving the file, if I run a ls -l on
the directory the file permissions on the file I opened are set to "hhayes"
as the owner with rw permission, and the group is set to "users" with only r
permission. I am not deleting the file and recreating it, onl
Wow, this is so completely OT I like it...
On Wednesday, 2004-02-18 at 13:58:59 +0100, Ivan Brezina wrote:
> hmm, xargs does not use quotes when executing commands. This causes
> problems with dirs with spaces in name.
> If user has directory named "dummy root", he can easily get accsess to
> /
On Wed, Feb 18, 2004 at 01:58:59PM +0100, Ivan Brezina wrote:
> [...]
>
> hmm, xargs does not use quotes when executing commands. This causes
> problems with dirs with spaces in name.
> If user has directory named "dummy root", he can easily get accsess to
> /root directory.
Use "find -print0" a
Changing the umask to 007 didn't have any effect on the problem. So far
I've tried 000 and 007.
You said:
> 2) Referring back to your original post, the only user who can change
> the owner of a file is the owner of that file, with the chown command.
> For someone else to apparently change the ow
On Thu, Feb 19, 2004 at 12:19:31AM +1100, Russell Coker wrote:
> Regardless, you will still have the same problem if a user creates hard links
> to files owned by another user (presuming that you don't have a mount point
> per user or a file system such as NFS that doesn't support hard-links).
N
On Thu, 19 Feb 2004 00:23, Javier Fernández-Sanguino Peña <[EMAIL PROTECTED]>
wrote:
> On Wed, Feb 18, 2004 at 11:50:27PM +1100, Russell Coker wrote:
> > If you are going to change such things then you need to use the -uid or
> > -gid options to find (depending on whether you are changing the UID
On Wed, Feb 18, 2004 at 11:50:27PM +1100, Russell Coker wrote:
> If you are going to change such things then you need to use the -uid or -gid
> options to find (depending on whether you are changing the UID or GID), and
> you need to do it when the machine is in single-user mode (IE no-one can
>
On Wed, 18 Feb 2004 23:59, Javier Fernández-Sanguino Peña <[EMAIL PROTECTED]>
wrote:
> On Wed, Feb 18, 2004 at 11:05:30AM +0100, Richard Atterer wrote:
> > Waah, SCARY!
> >
> > Users can create hard links to arbitrary files in that directory, e.g.
> > links to other users' private files or to
Kristopher Matthews wrote:
This is a security nightmare. I would *not* recommend doing any such
thing in a user filesystem.
You're making the assumption that he LIKES his users. :)
On Wed, 18 Feb 2004, Michael Stone wrote:
On Wed, Feb 18, 2004 at 02:15:36AM +0100, Javier Fernández-Sanguino
On Wed, Feb 18, 2004 at 11:05:30AM +0100, Richard Atterer wrote:
> Waah, SCARY!
>
> Users can create hard links to arbitrary files in that directory, e.g.
> links to other users' private files or to /etc/shadow, and automatically
> get read access to those files.
That is, of course, if the
On Wed, 18 Feb 2004 23:30, Kristopher Matthews <[EMAIL PROTECTED]> wrote:
> > This is a security nightmare. I would *not* recommend doing any such
> > thing in a user filesystem.
>
> You're making the assumption that he LIKES his users. :)
It's not a matter of whether the admin likes his users, it
> This is a security nightmare. I would *not* recommend doing any such
> thing in a user filesystem.
You're making the assumption that he LIKES his users. :)
On Wed, 18 Feb 2004, Michael Stone wrote:
> On Wed, Feb 18, 2004 at 02:15:36AM +0100, Javier Fernández-Sanguino Peña
> wrote:
> >DIR_TO_F
On Wed, Feb 18, 2004 at 02:15:36AM +0100, Javier Fernández-Sanguino Peña wrote:
DIR_TO_FIX=/home/groupX
GROUP=mygroup
PERM=g+rwX
find $DIR_TO_FIX -type f -o -type d | xargs chown $GROUP
# or chown -hR $GROUP $DIR_TO_FIX
find $DIR_TO_FIX -type f -o -type d | xargs chmod $PERM
# or chmod -hR $PE
On Thu, Feb 19, 2004 at 12:19:31AM +1100, Russell Coker wrote:
> Regardless, you will still have the same problem if a user creates hard links
> to files owned by another user (presuming that you don't have a mount point
> per user or a file system such as NFS that doesn't support hard-links).
N
On Thu, 19 Feb 2004 00:23, Javier Fernández-Sanguino Peña <[EMAIL PROTECTED]>
wrote:
> On Wed, Feb 18, 2004 at 11:50:27PM +1100, Russell Coker wrote:
> > If you are going to change such things then you need to use the -uid or
> > -gid options to find (depending on whether you are changing the UID
On Wed, Feb 18, 2004 at 11:50:27PM +1100, Russell Coker wrote:
> If you are going to change such things then you need to use the -uid or -gid
> options to find (depending on whether you are changing the UID or GID), and
> you need to do it when the machine is in single-user mode (IE no-one can
>
On Wed, 18 Feb 2004 23:59, Javier Fernández-Sanguino Peña <[EMAIL PROTECTED]>
wrote:
> On Wed, Feb 18, 2004 at 11:05:30AM +0100, Richard Atterer wrote:
> > Waah, SCARY!
> >
> > Users can create hard links to arbitrary files in that directory, e.g.
> > links to other users' private files or to
Kristopher Matthews wrote:
This is a security nightmare. I would *not* recommend doing any such
thing in a user filesystem.
You're making the assumption that he LIKES his users. :)
On Wed, 18 Feb 2004, Michael Stone wrote:
On Wed, Feb 18, 2004 at 02:15:36AM +0100, Javier Fernández-Sanguino Peñ
On Wed, Feb 18, 2004 at 11:05:30AM +0100, Richard Atterer wrote:
> Waah, SCARY!
>
> Users can create hard links to arbitrary files in that directory, e.g.
> links to other users' private files or to /etc/shadow, and automatically
> get read access to those files.
That is, of course, if the
On Wed, 18 Feb 2004 23:30, Kristopher Matthews <[EMAIL PROTECTED]> wrote:
> > This is a security nightmare. I would *not* recommend doing any such
> > thing in a user filesystem.
>
> You're making the assumption that he LIKES his users. :)
It's not a matter of whether the admin likes his users, it
> This is a security nightmare. I would *not* recommend doing any such
> thing in a user filesystem.
You're making the assumption that he LIKES his users. :)
On Wed, 18 Feb 2004, Michael Stone wrote:
> On Wed, Feb 18, 2004 at 02:15:36AM +0100, Javier Fernández-Sanguino Peña wrote:
> >DIR_TO_FIX=
On Wed, Feb 18, 2004 at 02:15:36AM +0100, Javier Fernández-Sanguino Peña wrote:
DIR_TO_FIX=/home/groupX
GROUP=mygroup
PERM=g+rwX
find $DIR_TO_FIX -type f -o -type d | xargs chown $GROUP
# or chown -hR $GROUP $DIR_TO_FIX
find $DIR_TO_FIX -type f -o -type d | xargs chmod $PERM
# or chmod -hR $PERM $
On Wed, Feb 18, 2004 at 02:15:36AM +0100, Javier Fernández-Sanguino Peña wrote:
> You can try to settle it by using umask (as other's have suggested) but
> users can defeat that. If you _really_ want to fix it, have a cronjob do
> this (quick and dirty, could be _really_ improved)
>
> --
On Wed, Feb 18, 2004 at 02:15:36AM +0100, Javier Fernández-Sanguino Peña wrote:
> You can try to settle it by using umask (as other's have suggested) but
> users can defeat that. If you _really_ want to fix it, have a cronjob do
> this (quick and dirty, could be _really_ improved)
>
> --
> 2) Referring back to your original post, the only user who can change
> the owner of a file is the owner of that file, with the chown command.
Even this is a little complex as a normal user can NOT give away ownership
of their files. I guess people were using the ability to avoid quota
limits
> 2) Referring back to your original post, the only user who can change
> the owner of a file is the owner of that file, with the chown command.
Even this is a little complex as a normal user can NOT give away ownership
of their files. I guess people were using the ability to avoid quota
limits
This probably belongs on the Debian User list rather than the Security
list, but anyway, here is your answer.
> What do I need to change the 022 setting to be for -rwxrwx--- ?
1) umask 007 will allow a user to create a file with permissions
-rw-rw or 0660. To make the file executable the
On Tue, Feb 17, 2004 at 03:12:44PM -0600, Hhayes wrote:
> I have a Debian box running as a file server on a network with 50 users. So
(...)
> saved the file, resulting in a file that no other users can write to. Has
> anyone ever seen this before?
Ejem, yes, it's called UN*X :-)
You can try to set
From the manual page of umask ( man umask ):
umask sets the umask to mask & 0777.
The umask is used by open(2) to set initial file
permissions on a newly-created file. Specifically, permissions in the
umask are turned off from the mode argument to open(2) (so, for
What do I need to change the 022 setting to be for -rwxrwx--- ?
"John Hardcastle" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> So the default file permissions don't do what you want.
> $ umask
> Read the manual page for the umask command,
> $ man umask
> As root, change the um
This probably belongs on the Debian User list rather than the Security
list, but anyway, here is your answer.
> What do I need to change the 022 setting to be for -rwxrwx--- ?
1) umask 007 will allow a user to create a file with permissions
-rw-rw or 0660. To make the file executable the u
Incoming from John Hardcastle:
>
> So the default file permissions don't do what you want.
> $ umask
> Read the manual page for the umask command,
> $ man umask
> As root, change the umask in /etc/profile to reflect the permissions you
> want.
> # vi /etc/profile
> Then have all users logout and
Where or how do I change my users umask?
"David Ehle" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> Sounds like you want to change your users umask if you want to change the
> behavior system wide, or maybe fiddle around with ACLs or set the
> directory sticky if it is just one p
On Tue, Feb 17, 2004 at 03:12:44PM -0600, Hhayes wrote:
> I have a Debian box running as a file server on a network with 50 users. So
(...)
> saved the file, resulting in a file that no other users can write to. Has
> anyone ever seen this before?
Ejem, yes, it's called UN*X :-)
You can try to set
So the default file permissions don't do what you want.
$ umask
Read the manual page for the umask command,
$ man umask
As root, change the umask in /etc/profile to reflect the permissions you
want.
# vi /etc/profile
Then have all users logout and login again. Their $HOME/.bashrc will
read /
From the manual page of umask ( man umask ):
umask sets the umask to mask & 0777.
The umask is used by open(2) to set initial file
permissions on a newly-created file. Specifically, permissions in the
umask are turned off from the mode argument to open(2) (so, for
What do I need to change the 022 setting to be for -rwxrwx--- ?
"John Hardcastle" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> So the default file permissions don't do what you want.
> $ umask
> Read the manual page for the umask command,
> $ man umask
> As root, change the um
Sounds like you want to change your users umask if you want to change the
behavior system wide, or maybe fiddle around with ACLs or set the
directory sticky if it is just one part of your file system.
David.
--
David Ehle
Computing Systems Manager
CAPP CSRRI
rm 077
LS Bld. IIT Main Campus
Chicag
You didn't mention what the file server daemon is. Samba? NFS? I
suspect Samba. If so, please include the relevant part of your
smb.conf... probably you just need to correct a mask setting in the share
config. If it is something else, please be more specific.
On Tue, 17 Feb 2004, Hhayes wro
Incoming from John Hardcastle:
>
> So the default file permissions don't do what you want.
> $ umask
> Read the manual page for the umask command,
> $ man umask
> As root, change the umask in /etc/profile to reflect the permissions you
> want.
> # vi /etc/profile
> Then have all users logout and
I have a Debian box running as a file server on a network with 50 users. So
far it works great except for the user/file permissions. I can go into a
directory and set the owner and group permissions to read/write on all
files in the directory and that works fine. Then as soon as one of the
user
Where or how do I change my users umask?
"David Ehle" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> Sounds like you want to change your users umask if you want to change the
> behavior system wide, or maybe fiddle around with ACLs or set the
> directory sticky if it is just one p
So the default file permissions don't do what you want.
$ umask
Read the manual page for the umask command,
$ man umask
As root, change the umask in /etc/profile to reflect the permissions you
want.
# vi /etc/profile
Then have all users logout and login again. Their $HOME/.bashrc will
read /etc
Sounds like you want to change your users umask if you want to change the
behavior system wide, or maybe fiddle around with ACLs or set the
directory sticky if it is just one part of your file system.
David.
--
David Ehle
Computing Systems Manager
CAPP CSRRI
rm 077
LS Bld. IIT Main Campus
Chicag
You didn't mention what the file server daemon is. Samba? NFS? I
suspect Samba. If so, please include the relevant part of your
smb.conf... probably you just need to correct a mask setting in the share
config. If it is something else, please be more specific.
On Tue, 17 Feb 2004, Hhayes wro
I have a Debian box running as a file server on a network with 50 users. So
far it works great except for the user/file permissions. I can go into a
directory and set the owner and group permissions to read/write on all
files in the directory and that works fine. Then as soon as one of the
user
71 matches
Mail list logo
