fcisler
asked on
tricky CHMOD
this is a bit of a tricky situation, so lemme explain first:
compaq desktop, openBSD 3.5
samba (newest version as of 2 weeks ago)
vsftpd (nothing less, again, latest version)
samba configured for 2 users (maybe more, all have equal permissions)
/share mounted on a 40gb hd
/share/video mounted on a 120gb hd
/share/audio '' '' '' 80gb hd
/share/software on the 40gb, regular folder
/share/incoming ''
one laptop, just for mobile use, needs same permissions as desktop
one desktop, runs shareazza (it's windows, it will get trashed sooner or later, but my files are all on BSD so they will last forever)....writes the temp (while downloading) files to local hd, final storage is on /share. files are then moved around into dirs as see fit
heres my goal:
right now it all works, i manually have to chmod several things and chown several things for different situations
i also run a ftp as all of this
ftp is vsftpd, config i dont think is that important, but key parts are it has no chmod permission (dont need it, use ssh for it) and no other permissions...just r+w...user is ftp
key system accounts:
root (duh), fcisler, ftp, share, public
fcisler = me (would like to have full permission of /share)
ftp = ftp account (system)
share = user and group of all /share...also what samba aliases too
public = ftp user account (public user)
all are system accounts
when i put a file in via samba i get permissions of 764...../share/incoming is owned by root, group is share, 777, the user "public" puts files into there as public, group is share, 755
everything else is owned by share, and group share, 755
it all works, although is a bit of pain for matinence
i know i can probally chown the ftp (vsftpd.conf) incoming and maybe samba (smb.conf), BUT what is the best way for it all to be managed through a windows computer?
-I want the /share/incoming to be writeable and resumeable by "public" and every other user, but not readable by public. Every other dir /share/* (minus incoming) should be full access by fcisler (ssh and samba) and share (just samba).
-All files that come in by samba should allready be set to same permission as /share/* (- incoming)
-General security for all files....it is running ftp, so public should be able to read /share/* but not modify, and not read /share/incoming, but upload and resume
This one is tricky, it deals with alot of permission and probally sticky bits (i still dont know what they do specifically), so heres the breakdown
-provide me permissions, user and groups for /share/*
-permissions, user, groups for /share/incoming/
-provide for both folder and files
-provide what ftp user should write to /share/incoming as
And i will give you the points, if you can explain it really well, AND/OR provide parts of smb.conf and vsftpd.conf where i should look, i can increase the points.....
Thanks in advance for help, if you have any questions...ask
compaq desktop, openBSD 3.5
samba (newest version as of 2 weeks ago)
vsftpd (nothing less, again, latest version)
samba configured for 2 users (maybe more, all have equal permissions)
/share mounted on a 40gb hd
/share/video mounted on a 120gb hd
/share/audio '' '' '' 80gb hd
/share/software on the 40gb, regular folder
/share/incoming ''
one laptop, just for mobile use, needs same permissions as desktop
one desktop, runs shareazza (it's windows, it will get trashed sooner or later, but my files are all on BSD so they will last forever)....writes the temp (while downloading) files to local hd, final storage is on /share. files are then moved around into dirs as see fit
heres my goal:
right now it all works, i manually have to chmod several things and chown several things for different situations
i also run a ftp as all of this
ftp is vsftpd, config i dont think is that important, but key parts are it has no chmod permission (dont need it, use ssh for it) and no other permissions...just r+w...user is ftp
key system accounts:
root (duh), fcisler, ftp, share, public
fcisler = me (would like to have full permission of /share)
ftp = ftp account (system)
share = user and group of all /share...also what samba aliases too
public = ftp user account (public user)
all are system accounts
when i put a file in via samba i get permissions of 764...../share/incoming is owned by root, group is share, 777, the user "public" puts files into there as public, group is share, 755
everything else is owned by share, and group share, 755
it all works, although is a bit of pain for matinence
i know i can probally chown the ftp (vsftpd.conf) incoming and maybe samba (smb.conf), BUT what is the best way for it all to be managed through a windows computer?
-I want the /share/incoming to be writeable and resumeable by "public" and every other user, but not readable by public. Every other dir /share/* (minus incoming) should be full access by fcisler (ssh and samba) and share (just samba).
-All files that come in by samba should allready be set to same permission as /share/* (- incoming)
-General security for all files....it is running ftp, so public should be able to read /share/* but not modify, and not read /share/incoming, but upload and resume
This one is tricky, it deals with alot of permission and probally sticky bits (i still dont know what they do specifically), so heres the breakdown
-provide me permissions, user and groups for /share/*
-permissions, user, groups for /share/incoming/
-provide for both folder and files
-provide what ftp user should write to /share/incoming as
And i will give you the points, if you can explain it really well, AND/OR provide parts of smb.conf and vsftpd.conf where i should look, i can increase the points.....
Thanks in advance for help, if you have any questions...ask
gheist
when parent directory is g+s or u+s it inherits respective uid/gid on file creation .
ASKER
gheist:
but it dosen't, i did a chmod -R 1755 before i did any of the scenarios above, and it's still the same situation....sticky bit is set, and it dosent make a difference
as far as if i am root or fcisler and do nano /share/video/test.txt then yes, the permission will be set, but i will do that 1/1000th of the time, rest of the time it is samba or ftp
but it dosen't, i did a chmod -R 1755 before i did any of the scenarios above, and it's still the same situation....sticky bit is set, and it dosent make a difference
as far as if i am root or fcisler and do nano /share/video/test.txt then yes, the permission will be set, but i will do that 1/1000th of the time, rest of the time it is samba or ftp
you just set sticky bit on directory, so it behaves more like /tmp
set g+s for desired effects
man chmod ; man sticky for more info
set g+s for desired effects
man chmod ; man sticky for more info
ASKER
gheist:
not to sound obnoxious, but don't you think i have read the man? i also have told you that i set sticky bit on the directory and all files (chmod -R 1755 * has the effect) and it still does not inheret permissions for FTP or for samba.....i am not saying it isnt smb.conf or vsftpd.conf, but the sticky bit means nothing in this case....
instead of telling me set the sticky bit, maybe you could give more insight into what i would want the rest of the permissions to be....
i am not asking "hold my hand and show me how to do it", i teach myself what i need to learn
and as i said, it is working....i am just curious as to what other ways i can acomplish this.....
not to sound obnoxious, but don't you think i have read the man? i also have told you that i set sticky bit on the directory and all files (chmod -R 1755 * has the effect) and it still does not inheret permissions for FTP or for samba.....i am not saying it isnt smb.conf or vsftpd.conf, but the sticky bit means nothing in this case....
instead of telling me set the sticky bit, maybe you could give more insight into what i would want the rest of the permissions to be....
i am not asking "hold my hand and show me how to do it", i teach myself what i need to learn
and as i said, it is working....i am just curious as to what other ways i can acomplish this.....
# smb.conf:
[share]
path = /path/to/share
create mode = 755
; or 644 if not executable
directory mask = 2775
force group = your-prefered-group-here
the initial directory still have g+s set, so restart samba and it should do the trick.
For ftp it depends on your ftpd, usually there is a umask configuration setting
[share]
path = /path/to/share
create mode = 755
; or 644 if not executable
directory mask = 2775
force group = your-prefered-group-here
the initial directory still have g+s set, so restart samba and it should do the trick.
For ftp it depends on your ftpd, usually there is a umask configuration setting
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
fcisler.
FYI. Setting the sticky bit on a directory (not applicable for files), means that only the owner of the file can delete it if you don't have write permission on the file.
FYI. Setting the sticky bit on a directory (not applicable for files), means that only the owner of the file can delete it if you don't have write permission on the file.
ASKER
de2Zotjes:
Thank you, very good suggestions....couple questions:
1) Groups "share" has users "fcisler" and "share" in it, so this will be my group....should share or fcisler have ownership? Share, right?
2) new folders should be chmod'd to 2775, and new dir's to 0664... or did you mean 1775 for dirs (why would i want setgid?) correct?
3) as a quick and dirty fix for the incoming dir, could i deny execute, so they cannot get a dir listing? that way they can upload a file (and resume) but not list any files? would that work?
Thanks for the help, gonna test it out now
Thank you, very good suggestions....couple questions:
1) Groups "share" has users "fcisler" and "share" in it, so this will be my group....should share or fcisler have ownership? Share, right?
2) new folders should be chmod'd to 2775, and new dir's to 0664... or did you mean 1775 for dirs (why would i want setgid?) correct?
3) as a quick and dirty fix for the incoming dir, could i deny execute, so they cannot get a dir listing? that way they can upload a file (and resume) but not list any files? would that work?
Thanks for the help, gonna test it out now
Hi,
1) ownership is basically up to you, I would try to set it to the user that is most active on the filesystem.
2) folders ( = directories ) should be 2775, files 0664. The role of the setgid-bit is different for a directory than it is for a file, you want setgid because when set on a directory setgid will cause all new files created in that directory to have the same group as the parent directory.
3) Again the role of the bits is slightly different for dorectories than it is for files. The execute bit does not control reading the directory, it controls the ability to "cd" to that directory. If you want the world to be able to write but not read, then set the bits to just that: chmod o-r+w /share/incoming. Leave the execute bit set.
1) ownership is basically up to you, I would try to set it to the user that is most active on the filesystem.
2) folders ( = directories ) should be 2775, files 0664. The role of the setgid-bit is different for a directory than it is for a file, you want setgid because when set on a directory setgid will cause all new files created in that directory to have the same group as the parent directory.
3) Again the role of the bits is slightly different for dorectories than it is for files. The execute bit does not control reading the directory, it controls the ability to "cd" to that directory. If you want the world to be able to write but not read, then set the bits to just that: chmod o-r+w /share/incoming. Leave the execute bit set.
1) "share" is a group, so it could not have ownership, If I understand your description corrctly
2) new folders should be chmod'd to 2775, and new dir's to 0664 ...
what is a folder for you?
Unix only have dirs, and for your purpose they should hav 27xx (where xx to be replaced for your needs)
About 17xx see previous comment: it enforces that anything in that dir can only be deleted by the owner
3) you're correct that a missing x-bit denies the listing, but if Samba can write then anyway needs to be tested, sorry I don't know for shure
2) new folders should be chmod'd to 2775, and new dir's to 0664 ...
what is a folder for you?
Unix only have dirs, and for your purpose they should hav 27xx (where xx to be replaced for your needs)
About 17xx see previous comment: it enforces that anything in that dir can only be deleted by the owner
3) you're correct that a missing x-bit denies the listing, but if Samba can write then anyway needs to be tested, sorry I don't know for shure
ASKER
de2Zotjes:
Thank you again. Part of this looks a bit wacky to me.
If i do a ls -l in /share i get the following
drwxrwsr-t 31 share share 1636 Oce 17 22:07 audio
etc
drwxrwsrwx etc etc incoming
Breakdown:
d means dir
rwx = read + write + execute
rws = read + write + execute (with sticky bit set?)
r-t = read + sticky bit (also executable?)
am i correct? is this what i want?
ls -l /share/audio/onyx
-rwxrwxr-t share share etc filename.mp3
is this correct again?
I'm trying to get these permissions set, test it out with samba, then i wanna work on vsftpd, because there is a chown_uploade flag, but no chmod uploads flag...i'm going to play around with owner and group of incoming and see what different effects it has on uploads via ftp and control via samba.....
thanks again for the help
Thank you again. Part of this looks a bit wacky to me.
If i do a ls -l in /share i get the following
drwxrwsr-t 31 share share 1636 Oce 17 22:07 audio
etc
drwxrwsrwx etc etc incoming
Breakdown:
d means dir
rwx = read + write + execute
rws = read + write + execute (with sticky bit set?)
r-t = read + sticky bit (also executable?)
am i correct? is this what i want?
ls -l /share/audio/onyx
-rwxrwxr-t share share etc filename.mp3
is this correct again?
I'm trying to get these permissions set, test it out with samba, then i wanna work on vsftpd, because there is a chown_uploade flag, but no chmod uploads flag...i'm going to play around with owner and group of incoming and see what different effects it has on uploads via ftp and control via samba.....
thanks again for the help
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
just been messing around with it, couple thing
changed find /share -type f --exec chmod ug+rw,o-w+r \{} \; to
find /share -type f -exec chmod ug=rw,o=r \{} \;
and find /share -type d --exec chmod a+x,u+rw,g+rws,o-w+r to
find /share -type d -exec chmod u=rwx,g=rwxs,o=r
and ran it to replace all my old permissions, so now each dir looks like
drwxrwsr-t which is what i believe i want
BUT
each file now has
-rw-rw-r-T
i believe i want all of that, but not sure what T is....does that mean it's inhereting sticky? is this a good security setting for all the files/folders?
thanks
changed find /share -type f --exec chmod ug+rw,o-w+r \{} \; to
find /share -type f -exec chmod ug=rw,o=r \{} \;
and find /share -type d --exec chmod a+x,u+rw,g+rws,o-w+r to
find /share -type d -exec chmod u=rwx,g=rwxs,o=r
and ran it to replace all my old permissions, so now each dir looks like
drwxrwsr-t which is what i believe i want
BUT
each file now has
-rw-rw-r-T
i believe i want all of that, but not sure what T is....does that mean it's inhereting sticky? is this a good security setting for all the files/folders?
thanks
sticky bit is needed for /tmp, /var/tmp /usr/tmp, and nowhere else, get it out of your head please.
historically it sticks binary programs into memory, so they run faster, but no modern system supports this, since normal coloured and unified buffer cache handles main purpose of sticky bit just fine.
historically it sticks binary programs into memory, so they run faster, but no modern system supports this, since normal coloured and unified buffer cache handles main purpose of sticky bit just fine.
ASKER
gheist,
then why are ahoffmann and de2Zotjes suggesting i use it on the dirs? man sticky gives "...indicate special treatment for directories"...it says nothing of sticking binary programs into memory, maybe you can elaborate on why i dont need it?
then why are ahoffmann and de2Zotjes suggesting i use it on the dirs? man sticky gives "...indicate special treatment for directories"...it says nothing of sticking binary programs into memory, maybe you can elaborate on why i dont need it?
There is some confusion about the names of various bits that can be set.
There are 3 bits that we are talking about here: setuid, setgid, sticky.
So in essence gheist is right in saying that you do not need (or want) to set the sticky bit. However a lot of times the setuid and setgid bits are referred to as "sticky bits" when people are talking about them in relation to directories. This arises from the function that these bits have when set on a directory: they make the owner or group "sticky". It is an unfortunate clash of names that occurs...
There are 3 bits that we are talking about here: setuid, setgid, sticky.
So in essence gheist is right in saying that you do not need (or want) to set the sticky bit. However a lot of times the setuid and setgid bits are referred to as "sticky bits" when people are talking about them in relation to directories. This arises from the function that these bits have when set on a directory: they make the owner or group "sticky". It is an unfortunate clash of names that occurs...
and ffs supports few extra bits via chflags and setfacl commands, especially uchg ,which will ensure that gid of file is not changed by nasty programs like samba or ftp servers
http://www.openbsd.org/cgi-bin/man.cgi?query=sticky&apropos=0&sektion=0&manpath=OpenBSD+2.2&arch=i386&format=html
and please do not start asking just what is the text and how to type it or so.
and please do not start asking just what is the text and how to type it or so.
sticky, setuid etc.
and another often used term is s-bit
As de2Zotjes explained, you need to know which s-bit you mean when saying "sticky". Think I used it correct: sticky is o+s
About o+s on directories: in most cases it behaves as described: only owner of a file can modify/delete it in a "sticky directory".
But AFAIK this depends on the filesystem, currently I don't know of any which behaves different (old ufs on SunOS does).
fcisler, did you check your smb.conf settings, in particular "create mode" and "directory mask"
and another often used term is s-bit
As de2Zotjes explained, you need to know which s-bit you mean when saying "sticky". Think I used it correct: sticky is o+s
About o+s on directories: in most cases it behaves as described: only owner of a file can modify/delete it in a "sticky directory".
But AFAIK this depends on the filesystem, currently I don't know of any which behaves different (old ufs on SunOS does).
fcisler, did you check your smb.conf settings, in particular "create mode" and "directory mask"
Ahoffman: o+s is meaningless, it iseither o+t which is the sticky bit, or u+s which is the setuid bit
ASKER
de2Zotjes and ahoffmann, thank you....you have both been very helpfull....i'm going to raise points to 500 and split between you....
gheist....you sound like you have a serious anger problem or something.....i quote from my previous post
"man sticky gives "...indicate"
do you not think i know how to read the man pages?
was i not asking the question for help, and to understand the difference between the three "sticky" bits? i think i have a good enough general understanding now to where i can sort out the little quirks myself.....but you seem to just try and put me down and act like i am an idiot....it's not appreciated nor warranted....thanks to the others who helped....
gheist....you sound like you have a serious anger problem or something.....i quote from my previous post
"man sticky gives "...indicate"
do you not think i know how to read the man pages?
was i not asking the question for help, and to understand the difference between the three "sticky" bits? i think i have a good enough general understanding now to where i can sort out the little quirks myself.....but you seem to just try and put me down and act like i am an idiot....it's not appreciated nor warranted....thanks to the others who helped....
> o+s
damn, have to be o+t for shure, sorry
damn, have to be o+t for shure, sorry