mainSavannah Administration - Support: sr #105838, Cannot set SGID bit on directory...

 
 

sr #105838: Cannot set SGID bit on directory in Download area

Submitter:  Eric NOULARD <erk>
Submitted:  Tue 24 Apr 2007 02:53:45 PM UTC
   
 
Category:  Download area - developer access Priority:  5 - Normal
Severity:  3 - Normal Status:  Done
Privacy:  Public Assigned to:  Beuc
Operating System:  None Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

  Spam posted by anonymous
Thu 26 Apr 2007 07:20:06 AM UTC, comment #5: 


Yes I did file the bug in their bugzilla:
http://bugzilla.mindrot.org/show_bug.cgi?id=1310

Thanks you for the directories owned by svusers
I didn't see that, this is fixed now.


Eric NOULARD <erk>
Thu 26 Apr 2007 06:28:34 AM UTC, comment #4: 

Thanks for the OpenSSH report. Apparently they agree that this should be fixed. Did you send a report to their bugzilla as well?

For the symlink issue:
/srv/download/tsp/prebuilt/windows is setgid, but has group 'svusers'. This means that files and symlinks will get a default 'svusers' group. You need to 'chgrp' it.

Sylvain Beucler <Beuc>
Tue 24 Apr 2007 11:14:07 PM UTC, comment #3: 

Hi,

I have:

1) sent a message to OpenSSH project:
   http://marc.info/?l=openssh-unix-dev&m=117745562123264&w=4
   (no answer [yet])

2) I manage to change all directories permissions using
   the following procedure:
 
   mkdir TSP_DA
   scp -r erk@dl.sv.nongnu.org:/releases/tsp TSP_DA
   mkdir TSP_DA_dironly
   cd TSP_DA
   find . -type d -exec mkdir ../TSP_DA_dironly/{} \;
   cd ../TSP_DA_dironly
   chmod -R g+ws tsp/
   scp -rp tsp/ erk@dl.sv.nongnu.org:/releases


Then all permissions seems to be "right" for now.

During my review of those permissions issue I noticed
that symlinks created using sftp "symlink" command
display "svusers" group instead of "tsp" (project group)
you may check this in tsp download area there:
sftp> pwd
Remote working directory: /srv/download/tsp/prebuilt/windows
sftp> ls -l
lrwxrwxrwx    1 erk      svusers        72 Apr 24 22:04 tsp-0.8.2-Windows.exe
lrwxrwxrwx    1 erk      svusers        76 Apr 24 22:04 tsp-0.8.2-Windows.exe.sig
sftp>

thoses files are symlinks to:
sftp> pwd
Remote working directory: /srv/download/tsp/tsp-0.8.x/tsp-0.8.2/prebuilt/windows
sftp> ls -la
drwxrwsr-x    2 erk      tsp          4096 Apr 24 22:13 .
drwxrwsr-x    3 erk      tsp          4096 Apr 24 22:13 ..
-rwxr-xr-x    1 erk      tsp       5003981 Nov 29 08:42 tsp-0.8.2-Windows.exe
-rwxr-xr-x    1 erk      tsp            65 Nov 29 08:42 tsp-0.8.2-Windows.exe.sig
sftp>

It is not a "real" issue since even if group is not
the appropriate one the symlink work as expected.

Eric NOULARD <erk>
Tue 24 Apr 2007 04:56:04 PM UTC, comment #2: 

Ok I will ask for feature/bug to OpenSSH project.

I did try the local chmod +s  + scp -r
but I did forget the -p scp option  :((

Will do it again soon and tell you what happen.

Thanks


Eric NOULARD <erk>
Tue 24 Apr 2007 04:16:43 PM UTC, comment #1: 

Hi,

In principle this should be done automatically: the top-level directory is setgid, and there's a default umask of 002 for every SSH connection.

Now if for some reason the mode was changed, then you indeed need to set it back for collaborative work.

Unfortunately, from what I can see in the sftp source code, the sftp server does a '& 0777' before applying the chmod, which unsets the setgid even if you specify it explicitely.
Can you please report this bug (feature?) to the OpenSSH project and check out why it's done that way?


Meanwhile, you can work around via the rsync and sftp access:

local$ cd /tmp
local$ mkdir -m 2775 mydir
local$ scp -rp mydir me@dl.sv.gnu.org:/releases/myproject/
# or
local$ rsync -a mydir/ me@dl.sv.gnu.org:/releases/myproject/mydir/
# or (shorter)
local$ rsync -a mydir me@dl.sv.gnu.org:/releases/myproject/


Beware that you may have uploaded new directories in non-setgid ones. In this case the system sets the directory group to 'svusers'. Then sftp is a pain again and asks you to chgrp the directory using the group number, not the group name. You can get this group number through:
sftp> ls -lan /releases/myproject
Then:
sftp> chgrp 3698 /releases/myproject/mynonsetgiddir/dir2

Let me know if you can do everything without admin intervention.

Sylvain Beucler <Beuc>
Tue 24 Apr 2007 02:53:45 PM UTC, original submission:  

We (TSP administrator) have switched to sftp/scp
for download area management:
http://download.savannah.nongnu.org/releases/tsp/

Since we are several admin we want to be able
to work with file/directory permissions on a group basis.

I tried to chmod 2775 <whatever/path/todir>
with sftp and obtained nothing different than 775.

Is it possible
to have SETGID bit sets on each subdirs of
TSP project download area?

Moreover could we do it ourself?
And if yes how?


Eric NOULARD <erk>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by Beuc (Posted a comment)
  • -email is unavailable- added by erk (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2008-03-15 Beuc StatusNone Done
        Open/ClosedOpen Closed
    2007-04-24 Beuc Assigned toNone Beuc
    2007-04-24 erk Carbon-Copy- Added deweerdt

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code