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. Has
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. Has
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 nice if
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 would be
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 nice if
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 would be
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:
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
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:
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's
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
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, 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
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 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 or
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).
NFS
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
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 and xargs
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
/root
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, only
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
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
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
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
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
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,
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
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:
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
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:
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's
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
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
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
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 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 or
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).
NFS
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
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 and xargs
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
/root
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, only
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 part of
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 login
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 umask in
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
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
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
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
64 matches
Mail list logo
