bugGNU CSSC - Bugs: bug #36269, "sccs create" loses...

 
 

bug #36269: "sccs create" loses execute permissions

Submitter:  None
Submitted:  Sun 22 Apr 2012 01:47:08 AM UTC
   
 
Category:  None Severity:  3 - Normal
Item Group:  None Status:  Fixed
Privacy:  Public Assigned to:  jay
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sat 11 May 2019 06:40:13 AM UTC, comment #6: 

This is fixed in CSSC release 1.4.1.

James Youngman <jay>
Group administrator
Wed 06 Aug 2014 12:22:05 PM UTC, comment #5: 

Just a note: SCCS does not intend to exactly reproduce the
permissions of a file. It just likes to permit a user to make
a script executable in order to be able to check it.

BitKeeper SCCS does include support for reproducing arbitrary
permissions but this is not really compatible with the ideas
of SCCS. Future versions of SCCS may incluse some kind of similar
support.

The man pages of the original SCCS have been rewritten to include
more information. This includes previously undocumented feaatures
that some people may rely on. I recommend you to have a look at
the SCCS man pages at:

http://sccs.sourceforge.net/man/index.html

in special at:

http://sccs.sourceforge.net/man/sccsfile.4.html

as this now includes some information about propertoes where
CSSC deviates from SCCS.

See also sccs.sourceforge.net for the SCCS homepage.

Jörg Schilling <schily>
Mon 28 Jul 2014 12:30:39 AM UTC, comment #4: 

I reconsidered my previous position.

It's least astonishing for us to treat execute bits as we do read bits; if the umask permits, the gotten file is world-readable; the previous mode of other files doesn't affect it.   Hence if the history file is executable it's least surprising for the gotten file to be mode 0777 (modified by the umask).   This is the Solaris behaviour.

Setting world-execute permissions on the gotten file is unlikely to grant additional access to anybody since (subject to umask) they can read the gotten file anyway (hence copy it and chmod it themselves).

I've implemented the feature: http://git.savannah.gnu.org/cgit/cssc.git/commit/?id=cb5e4ca42dc01103228d662911be5144da4cb2d5

James Youngman <jay>
Group administrator
Sun 20 Jul 2014 11:01:42 PM UTC, comment #3: 

Correction -- remove a spurious "not":

mode 0666 (if the original file was not owner-executable) or mode 0777 (if the original file was owner-executable).

James Youngman <jay>
Group administrator
Sun 20 Jul 2014 10:59:57 PM UTC, comment #2: 

I'm inclined to implement the feature, but closely following the behaviour of Solaris 10 in particular (I didn't check other versions) may not be the best approach, since that implementation somewhat violates the principle of least astonishment:

When reading the input file (named via admin -i, for example) only the owner's execute permission bit is significant.   The setting of this bit is copied however to all three of the execute bits in the history file [note 1] if the input , and in turn that is copied to the mode bits of the subsequent gotten file.

The result is that you take a file executable by owner only, check it into SCCS, check it out again, and suddenly it's world-executable (depending on your umask).


[note 1]: I assume this happens because the history file and the gotten file are created with mode 0666 (if the original file was not owner-executable) or mode 0777 (if the original file was not owner-executable).


 ( for mask in 0111 0011 0001 0000; do umask $mask; echo; echo umask=$mask; rm -f
s.x; touch x; chmod 0750 x; echo Original mode:; ls -ld x; admin -i s.x < x 2>/dev/null  ; echo Mode of resulting history file:; ls -l s.x; rm -f x; get s.x >/dev/null 2>&1; echo Mode of gotten file:; ls -l x; rm -f x s.x; done )

umask=0111
Original mode:
-rwxr-x---   1 jay      csw            0 Jul 21 00:48 x
Mode of resulting history file:
-r--r--r--   1 jay      csw          146 Jul 21 00:48 s.x
Mode of gotten file:
-r--r--r--   1 jay      csw            0 Jul 21 00:48 x

umask=0011
Original mode:
-rwxr-x---   1 jay      csw            0 Jul 21 00:48 x
Mode of resulting history file:
-r-xr--r--   1 jay      csw          146 Jul 21 00:48 s.x
Mode of gotten file:
-r-xr--r--   1 jay      csw            0 Jul 21 00:48 x

umask=0001
Original mode:
-rwxr-x---   1 jay      csw            0 Jul 21 00:48 x
Mode of resulting history file:
-r-xr-xr--   1 jay      csw          146 Jul 21 00:48 s.x
Mode of gotten file:
-r-xr-xr--   1 jay      csw            0 Jul 21 00:48 x

umask=0000
Original mode:
-rwxr-x---   1 jay      csw            0 Jul 21 00:48 x
Mode of resulting history file:
-r-xr-xr-x   1 jay      csw          146 Jul 21 00:48 s.x
Mode of gotten file:
-r-xr-xr-x   1 jay      csw            0 Jul 21 00:48 x



If the original file is not owner-executable, the history file (and this subsequent gotten files) are not executable at all:

( for mask in 0111 0011 0001 0000; do umask $mask; echo; echo umask=$mask; rm -f
s.x; touch x; chmod 0651 x; echo Original mode:; ls -ld x; admin -i s.x < x 2>/dev/null  ; echo Mode of resulting history file:; ls -l s.x; rm -f x; get s.x >/dev/null 2>&1; echo Mode of gotten file:; ls -l x; rm -f x s.x; done )

umask=0111
Original mode:
-rw-r-x--x   1 jay      csw            0 Jul 21 00:57 x
Mode of resulting history file:
-r--r--r--   1 jay      csw          146 Jul 21 00:57 s.x
Mode of gotten file:
-r--r--r--   1 jay      csw            0 Jul 21 00:57 x

umask=0011
Original mode:
-rw-r-x--x   1 jay      csw            0 Jul 21 00:57 x
Mode of resulting history file:
-r--r--r--   1 jay      csw          146 Jul 21 00:57 s.x
Mode of gotten file:
-r--r--r--   1 jay      csw            0 Jul 21 00:57 x

umask=0001
Original mode:
-rw-r-x--x   1 jay      csw            0 Jul 21 00:57 x
Mode of resulting history file:
-r--r--r--   1 jay      csw          146 Jul 21 00:57 s.x
Mode of gotten file:
-r--r--r--   1 jay      csw            0 Jul 21 00:57 x

umask=0000
Original mode:
-rw-r-x--x   1 jay      csw            0 Jul 21 00:57 x
Mode of resulting history file:
-r--r--r--   1 jay      csw          146 Jul 21 00:57 s.x
Mode of gotten file:
-r--r--r--   1 jay      csw            0 Jul 21 00:57 x




James Youngman <jay>
Group administrator
Tue 15 Jul 2014 01:32:22 PM UTC, comment #1: 

You may like to use the original SCCS then, see:

https://sourceforge.net/projects/sccs/files/

or

https://sourceforge.net/projects/schilytools/files/ for development snapshots

Jörg Schilling <schily>
Sun 22 Apr 2012 01:47:08 AM UTC, original submission:  

An "sccs create myfile" command, where myfile had execute permissions beforehand, destroys those execute permissions.  This is an inappropriate intrusion, and does not mirror the behavior of standard SCCS (e.g., on Solaris).  Standard SCCS copies the execute permissions to the SCCS/s.myfile file, and does not remove them from the original file.

Anonymous

 

(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 jay (Posted a comment)
  • -email is unavailable- added by schily (Posted a comment)
  •  

    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 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-05-11 jay Open/ClosedOpen Closed
    2014-07-28 jay StatusNone Fixed
    2014-07-20 jay Assigned toNone jay

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code